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1.  Chapter  One:  Executive  Summary 

1.1  Vision 

The  Training  and  Doctrine  Command's  (TRADOC)  core  processes  and  products  will  continue  to  be 
information  based.  TRADOC  will  acquire  information  from  worldwide  external  sources  as  well  as  from 
our  own  operations  and  experiments.  TRADOC  will  analyze  and  process  information  to  formulate  new 
concepts,  doctrine,  organizational  designs  and  materiel  requirements.  To  create  consensus  for  our 
products,  TRADOC  will  transport  information  to  worldwide  destinations.  To  ensure  products  have  a 
combined  arms  orientation  and  integrated  intellectual  content,  TRADOC  will  require  frequent,  and 
sometimes  large,  information  exchanges,  internal  and  external  to  the  command.  While  TRADOC  will 
generate  and  package  its  products  various  ways,  e.g., 

•  doctrine  as  publications  and  computer  media 

•  materiel  requirements  as  documents  and  demonstrations 

•  training  as  institutional  training  lectures,  videos  and  interactive  courseware 

—their  common  denominator  will  be  their  information  content.  In  short,  TRADOC's  mission  will  keep 
the  command  squarely  in  the  information  management  (IM)  business. 

TRADOC's  Strateeic  Plan  1997  recognizes  the  command's 
information  systems  (IS)  architecture  as  a  key  enabler  of 
mission  execution.  Our  mission  demands  we  build  an  IS 
architecture  to  acquire,  process,  transport,  package,  and  protect 
the  information  we  use  and  the  information  we  generate. 

TRADOC's  IS  architecture  will  be  sufficiently  robust  to  enable 
execution  of  TRADOC's  many  processes,  and  sufficiently 
flexible  to  retain  utility  as  reengineering  improves  our  processes. 

TRADOC's  Organization  Gnide  1997  gives  insight  into  our 
organization  for  mission  execution.  The  command  is  typified  by 
decentralized  execution  at  sixteen  installations  and  other 
activities  across  CONUS,  each  engaged  in  coordination  with  the 
others  and  with  organizations  and  units  throughout  the  Army 
and  DoD.  TRADOC's  decentralized  organization  will  continue 
to  drive  distributed  information  processing  and  robust 
information  transport  capabilities.  TRADOC  will  continue  to 
rely  on  action  officers  as  the  subject  matter  experts  that  execute 
our  processes  and  generate  our  products.  Access  to  TRADOC's  IS  architecture  will  therefore  extend 
capabilities  down  to  the  action  officer  level. 

Consistent  with  our  mission  and  organization,  TRADOC's  infrastructure  of  networks  and  computer 
platforms  will  provide  a  robust  command-wide  foundation  for  common  user  services  and  mission 
specific  applications,  and  will  remain  open  to  information  technology  insertion  to  support  uses  as  yet 
unimagined. 

The  networking  infrastructure  will  have  a  common  user  approach  that  can  provide  bandwidth  on 
demand,  rather  than  the  stovepipe  approach  that  dedicates  an  asset  to  one  application  or  set  of  users.  The 
infrastructure  will  provide  required  links  to  external  organizations  so  that  TRADOC  c^  transport  its 
products  wherever  necessary  and  acquire  information  from  the  best  data  sources.  The  infrastructure  will 
be  accessible  to  TRADOC  personnel  from  any  location  to  which  TRADOC's  mission  sends  them. 


Commander's  Intent 

"In  the  near  term,  we  will.. .identify 
key  enabling  investments  (such  as 
information  architectures  and 
distributive  interactive  simulations) 
and  press  for  their  rapid  integration... 

In  the  mid  term,  we  will... continue  the 
expansion  of  information 
architectures  and  automation  to 
increase  connectivity  to  all  training 
audiences— centers,  schools,  and  the 
operating  forces— across  the  Total 
Army..." 

TRADOC  Strategic  Plan,  1997 
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The  command's  information  resources,  or  data,  will  be  available  in  the  right  format  at  the  right  time 
and  place.  Information  will  be  structured  according  to  standard  formats  so  it  can  be  shared  and  reused. 
Seemed  interfaces  will  ensme  proper  user  access  and  data  integrity  while  still  maximizing  seamless 
information  transport.  Data  will  be  collected  one  time  and  then  shared  among  applications  to  create  a 
consistent  picture  of  the  command  for  its  decision  makers. 

Common  user  support  applications,  e.g.,  e-mail  and  databases,  will  be  interoperable  and  accessible 
where  needed,  whether  at  a  fixed  TRADOC  building  or  at  a  remote  traiiiing  site.  They  will  present  a 
consistent  interface  to  the  users.  They  will  enable  command-wide  coordination  for  distributed, 
collaborative  approaches  to  mission  execution. 

Mission  applications  will  optimize  their  domain  specific  architectmes  for  the  provision  of  unique 
capabilities,  but  will  be  capable  of  harnessing  the  standardized  capabilities  of  the  commands  networks, 
computing  platforms  and  data  structmes. 

1.2  Status 

TRADOC's  emrent  ISs  are  at  the  threshold  of  forming  such  a  flexible  and  robust  architectme. 
TRADOC  is  migrating  away  from  its  previous  inffastructme,  installed  in  the  mid  1980s,  which  was 
based  largely  on  dedicated  circuits,  proprietary  standards  and  a  mainframe  system  architecture. 
TRADOC's  recent  investment  strategy,  which  emphasizes  a  flexible,  open  architecture  of  distributed 
components,  linked  over  common  user  networks,  is  evident  in  improved  assets  and  on-going 
modernization  actions  across  the  command. 

TRADOC  has  achieved  a  common  baseline  for  wide 
area  network  (WAN)  and  campus  area  network  (CAN) 
capabilities  at  14  of  16  installations.  TRADOC's  WAN 
architecture  now  maximizes  use  of  the  common  user 
networks  collectively  managed  by  DoD  as  the  Defense 
Information  System  Network  (DISN).  An  immediate 
challenge  is  to  ensure  continued  networking  for  distributed 
interactive  simulations  since  DoD  has  stopped  its  central 
funding  for  the  Defense  Simulations  Internet  (DSI)  WAN. 

The  baseline  CANs,  based  on  fiber  distributed  data 
interface  (FDDI)  technology,  accommodate  data  transfer, 
but  do  not  support  higher  bandwidth  requirements  of  video 
or  distributed  simulations  required  by  the  Army  Distance 
T  earning  Plan  (ADLPI.  Force  XXI  experimentation  and 
other  Army-level  projects  executed  on  TRADOC 
installations.  To  address  this,  TRADOC  has  planned 
insertions  of  asynchronous  transfer  mode  (ATM) 
technology  into  key  CAN  segments,  interfaced  with 
switched  Ethernet  local  area  networks  (LANs)  to  extend 
adequate  bandwidth  to  the  users'  level.  Although  LANs 
are  commonplace  in  TRADOC,  networking  capabilities 
have  not  been  universally  extended  to  action  officer  level, 
inter-networked,  and  in  some  cases  created,  to  provide  connectivity  and  capabilities  at  the  level  required 
by  users.  Network  security  components,  at  WAN,  CAN  and  LAN  level,  are  inadequate  to  counter 
conceivable  threats.  Security  devices  are  also  required  to  realize  the  promise  of  intranets  for 
command-wide  coordination.  Intranets  employ  familiar  Internet  technology,  e.g.,  hypertext  links, 
graphic  user  interface  and  file  transfers,  while  controlling  access  to  sensitive  information. 

Although  the  IBM  mainframes  are  still  used  to  host  several  applications,  installations  have  made 
significant  progress  in  the  migration  to  more  distributed  and  open  platforms.  More  platform  insertions 
are  planned  in  the  near  term  by  DA  program  managers  but  installations  require  even  more  distributed 
servers,  particularly  to  provide  e-mail  compliant  with  the  Defense  Messaging  System  (DMS) 


Commander's  Assessment 

"Leading-edge  IT  [information  technology] 
and  connectivity  is  the  fundamental 
multiplier  for  providing  training  and  leader 
development  programs.  ..and  weapons 
system  development  process..  To  date  we 
have  accommodated  basic  needs  at  some  of 
our  installations  across  TRADOC  by 
providing  the  requisite  bandwidth  and 
thruput  needed  to  support  rapidly  emerging 
technologies.  However,  we  still  require 
funding  to  upgrade  the  remainder  of  our 
installations  to  this  capability  level.  Staying 
in  synch  with  technological  change,  as  it 
occurs,  is  essential. " 

CG  TRADOC  to  CSA 
3  Apr  97 
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client-server  architecture.  DMS  also  poses  a  significant  challenge  for  our  client  platforms,  i.e.,  personal 
computers  (PCs).  There  are  about  35,000  PCs  in  use  in  TRADOC.  Almost  as  many  are  Intel  386  and 
below  as  are  486  and  above.  386  PCs  are  inadequate  processing  platforms  for  working  with  TRADOC  s 
information  based  products.  HQ  TRADOC  coordinated  with  TRADOC  Directors  of  Information 
Management  (DOIMs)  to  issue  minimum  specifications  for  ordering  new  PCs.  These  minimum 
specifications  will  help  ensure  PCs  are  supportable,  interoperable  and  capable  of  running  common 
software  applications.  However,  there  are  inadequate  funds  to  modernize  sub-standard  hardware  and 
software  at  the  user  level.  Besides  slowing  the  migration  to  powerful  new  applications,  this  also 
prolongs  our  use  of  mixed  generations  of  office  automation  packages  and  impedes  free  exchange  of  our 
information  products. 


Many  of  the  mission  applications  managed  by  HQDA  or  DoD  program  managers  have  not  reached 
initial  operational  capability,  but  they  have  potential  to  move  TRADOC  closer  to  an  open  architecture 
than  the  mission  applications  they  replace.  Even  so,  such  systems  often  emphasize  the  optimization  of 
their  own  stovepipe  functional  domains  at  the  expense  of  the  conimand-wide  architecture,  and 
interoperability  problems  do  surface  during  integration  into  the  installations'  infrastructure.  Pending 
DoD  and  Army  fielding  of  mission  applications  fully  compliant  with  open  standards,  TRi^OC  still 
uses  Army  and  TRADOC  applications  that  are  based  on  a  non-standard  software  engineering 
environment.  TRADOC  must  integrate  replacement  capabilities.  Additionally,  these  replacements  must 
occur  prior  to  the  onset  of  problems  associated  with  the  change  of  the  century. 

The  change  of  the  century  has  the  potential  to  make  otherwise  serviceable  IS  components  obsolete 
unless  fixes  are  made.  In  some  cases,  the  problems  will  be  too  systemic  to  fix  and  replacement  systems 
will  have  to  be  found.  TRADOC  information  managers  are  still  assessing  the  impacts  to  determine  the 
scope  of  our  challenge. 

As  yet,  DoD  and  Army  have  fielded  few  capabilities  to  TRADOC  via  centrally  managed  programs, 
e.g.,  Power  Projection  Command,  Control,  Commumcations  and  Computers  Infrastructure  (PPC4I), 
Sustaining  Base  Information  Services  (SBIS),  and  DMS.  TRADOC's  own  IM  personnel  have  been 
reduced.  TRADOC's  IM  funding,  never  equal  to  its  requirements,  continues  to  shrink,  particularly  the 
OP  A,  or  investment,  funds.  Therefore,  TRADOC  is  choosing  its  modernization  investments  c^efully, 
emphasizing  key  enabling  investments  (KEI),  that  provide  the  best  opportunity  for  immediate  impact  on 
mission  essential  capabilities.  TRADOC  analyzes  each  KEI  to  identify  sm^  information  infrastnicture 
upgrades  that  must  support  the  more  visible  mission  applications.  Resourcing  will  remain  a  limiting 
factor  in  modernizing  TRADOC's  system  architecture.  In  the  commanders'  assessments  for  FY98,  seven 
TRADOC  installation  commanders  specifically  included  information  technology  modernization  as  an 
under  resourced  deficiency. 

In  summary,  TRADOC  faces  significant  near  term  resourcing  and  technical  challenges  to; 

•  Create  infrastructure  that  supports  high  bandwidth  video  and  simulation  applications 

•  Exploit  the  Internet  for  information  dissemination  and  document  staffing 

•  Migrate  to  the  DISN  Enhanced  IP  Services  (the  DSI  replacement),  and  fee-for-service 

•  Implement  DMS 

•  Eliminate  stovepipes 

•  Ensure  information  security 

•  Manage  change  of  century  (Y2K)  transition  issues 

1.3  Modernization  Drivers 

To  ensure  the  proper  focus,  IS  modernization  is  driven  by  TRADOC's  key  operational 
requirements.  Planning  the  solutions  for  these  requirements  is  undertaken  with  a  command-wide 
perspective,  guided  by  an  architecture  framework^  consistent  with  joint  and  Army  IS  architectural 
planning.  Within  this  fi-amework,  TRADOC's  specific  modernization  efforts  are  focused  by  a  set  of 
strategic  goals  for  achieving  the  architecture  and  otherwise  improving  the  command's  IM  processes. 
Like  a  combined  arms  team,  our  mix  of  information  systems  must  collectively  provide  the  right 
capabilities,  correctly  sized  and  orchestrated  for  an  optimum  response  to  mission  requirements. 
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1.3.1  Operational  Requirements 

To  meet  the  challenges  of  our  mission,  there  are  ongoing 
reengineering  initiatives  throughout  TRADOC.  These  efforts 
are  led  by  functional  proponents,  with  the  DCSIM  assisting 
since  nearly  all  will  impact  operational  requirements  for  IM 
support.  To  prepare  the  Army  for  war,  TRADOC  will 
continue  to  provide  quality  training  experiences  in  a  variety 
of  educational  settings  and  worldwide  locations.  TRADOC 
will  link  its  schoolhouses  to  soldiers  and  units  in  the 
operating  force  and  implement  the  distance  learning 
objectives  of  Classroom  XXI  and  the  ADLP.  As  the 
architect  of  the  future,  TRADOC  will  design  Force  XXI 
and  the  Army  After  Next.  TRADOC  will  generate  and  gain  Army-wide  agreement  for  orgamzational  and 
operational  concepts,  doctrine,  leader  developments,  materiel  requirements,  and  force  design.  TRADOC 
also  must  ensure  its  own  capability  to  execute  its  mission,  i.e.,  TRADOC  must  manage  installations 
assigned  to  the  command. 

See  also: 

4.1  Operational  architecture 

1.3.2  Architecture  Framework 

To  execute  all  the  tasks  implied  in  this  mission,  TRADOC  needs  IM  tools  that  work  in  a 
command-wide  interoperable  architecture.  In  executing  modernization  efforts,  TRADOC  will  apply 
principles  that  promote  the  creation  of  an  open,  standards  based,  architecture.  This  approach  will  best 
create  the  flexible  capabilities  and  robust  connectivity  required  by  our  information  based  mission  and 
distributed  organization.  Analyzing  TRADOC's  resource  environment,  it  seems  unlikely  we  will  field 
large  systems,  acquired  centrally  at  one  time,  with  all  interfaces  already  designed  and  engineered  for 
interoperability  by  the  vendor.  TRADOC  will  instead  grow  through  relatively  small,  decenfralized 
acquisitions  phased  over  time.  The  only  way  to  integrate  the  results  of  decentralized  acquisition 
decisions  is  to  establish  and  adhere  to  a  standards  profile,  guided  by  an  architectural  framework  for  the 
creation  of  command-wide  capabilities  and  information  flow.  TRAJDOC  must  build  toward  a  flexible 
architecture  into  which  small,  affordable,  components  can  be  integrated.  The  set  of  architectines  being 
developed  as  a  result  of  HQDA's  Enterprise  Strategy  provides  the  framework.  This  work  is  given  an 
even  broader  applicability  in  joint  architectures,  particularly  the  Joint  Technical  Architecture  (JTA).  As 
the  world-wide  information  technology  community  settles  on  standards  for  each  aspect  of  IM, 
incorporation  of  those  standards  into  acquisitions  permits  greater  reliance  on  advances  in  the  IS 
marketplace  for  workable  solutions  to  TRADOC  requirements.  TRADOC  will  also  use  prefeired 
products  lists  to  alert  users/buyers  about  which  products  will  have  full  DOIM  support  for  niaintenance, 
operations,  training,  etc.  In  August,  1997,  HQ  TRADOC  issued  the  first  such  coordinated  list  for 
command-wide  use.  It  addressed  user  level  IS  components.  Products  on  the  list  included  Microsoft  (MS) 
Windows  NT  Workstation,  MS  Office  applications,  and  MS  Exchange. 

See  also: 

2.1  Architecture  Framework 

4.4.3.2  Office  Automation 

1.3.3  Strategic  IM  Goals 

TRADOC's  strategic  goals  for  managing  IM  are  listed  in  Table  1.  Goals  1,  2  and  4  target  IS 
modernization  specifically,  while  the  others  are  aimed  at  improving  IM  processes  that  contribute  to  the 
efficiency  and  effectiveness  of  modernization.  These  strategic  IM  goals  guide  TRi^OC's  selection, 
approval  and  packaging  of  specific  modernization  efforts.  Each  goal  from  Table  1  is  defined  below. 

See  also: 


TRADOC's  Mission 

Prepare  the  Army  for  War 

Be  the  Architect  of America's  Army  for 
the  Future 

Ensure  TRADOC's  Capability  to  Execute 
its  Mission 

Strategic  Plan  1997 
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2.2  Strategic  Goals 


Table  1.  TRADOC IM  Goals 


~>1 

Improve  interoperability  of  TRADOC's  IS 

->2 

Modernize  IMA  infrastructure  to  meet  mission  requirements 

3 

Improve  the  process  for  managing  IMA  requirements  in  support  of  the 
command's  mission  requirements 

->4 

Better  incorporate  information  technology  in  support  of 

TRADOC  business  processes 

5 

Synchronize  IMA  actions  within  TRADOC 

6 

Design  appropriate  IMA  organizations  across  TRADOC 

— >  Goal  1:  Improve  interoperability  of  TRADOC's  IS 

IS  acquired  by  and  fielded  to  TRADOC  installations  must  form  an  integrated  tool  that  cost 
effectively  supports  command- wide  information  flow  as  required  by  current  missions  and  organizations; 
and  is  open  to  flexible  technology  insertions  to  retain  its  utility  as  reengineering  improves  our  processes. 
The  command  must  be  able  to  generate  and  capture  information  once,  and  share  it  among  all  TRADOC 
activities.  The  infrastructure  of  networks  and  platforms  must  have  interoperable  interfaces  with  mission 
applications.  Security  features  must  control  proper  user  access  while  still  maintaining  required 
information  flow.  There  must  be  commonality  among  TRADOC's  IS  tools  for  office  automation  and 
coordination  (e.g.,  e-mail,  schedulers,  dociunent  staffing)  so  that  they  can  rapidly  share  products  with  all 
information  content  preserved,  create  virtual  collocations  of  TRADOC  personnel,  and  can  be  redeployed 
and  reconfigured  as  necessary  to  flexibly  support  TRADOC's  missions  and  organizations.  TRADOC's  IS 
must  support  required  information  exchanges  with  deployed  forces  and  with  the  IS  of  units  in  garrison. 
TRADOC  must  be  in  compliance  with  the  Army  and  Joint  Technical  Architecture. 

— >  Goal  2:  Modernize  IMA  infrastructure  to  meet  mission  requirements 

Infrastructure  includes  common  user  communications  assets  and  processing  platforms. 
Modernization  is  required  to  meet  mission  requirements,  primarily  for  Classroom  XXI,  modeling  and 
simulations  and  command-wide  coordination  capabilities.  This  implies  increased  connectivity,  or  access 
points,  and  capacity,  or  bandwidth,  to  support  many  current  and  planned  applications  and  as  importantly, 
to  position  the  command  to  employ  new,  as  yet  undefined  applications  that  will  rely  on  robust 
information  transfer  and  information  processing  capabilities.  Platforms  must  be  migrated  toward  open 
systems  capable  of  supporting  client  server  software  architectures.  Modernization  must  be  implemented 
at  all  levels  (command,  installation,  building)  to  create  the  required  capability.  TRADOC  will  migrate 
from  many  sole  user  (dedicated)  links  to  fewer,  but  greater  capacity,  common  user  links  capable  of 
providing  bandwidth  on  demand. 

— >  Goal  3:  Improve  the  process  for  managing  IMA  requirements  in  support  of  the  command's  mission 
requirements 

TRADOC  will  reengineer  its  procedures  for  defining  and  integrating  IM  requirements  and  for 
transitioning  requirements  documentation  into  planning,  programming  and  resourcing  documents. 
TRADOC  must  have  clear  procedures  for  deciding  whether  proposed  solutions  and  procurement  actions 
fit  into  our  architectural  framework  and  for  rejecting  those  that  do  not.  The  procedures  must  ensure  the 
requirements  for  infrastructure  components  associated  with  key  mission  applications  are  identified  early 
and  resourced.  The  requirements  procedures  must  help  decision  makers  identify  the  high  payoff 
requirements,  i.e.,  key  enabling  investments,  that  deserve  a  high  priority,  reengineering  must  be 
implemented  in  the  context  of  TRADOC's  increased  role  for  Army- wide  requirements  management  and 
the  recent  elimination  of  unique  IS  procedures  in  the  AR  25  regulatory  series. 

— >  Goal  4:  Better  incorporate  information  technology  in  support  of  TRADOC  business  processes 
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TRADOC  will  ensure  its  reengineering  activities  consider  the  impact  that  information  technology  can 
have.  Information  managers  must  advise  TRADOC's  decision  micers  and  proponents  in  the  analysis  of 
alternatives,  from  the  perspective  of  available  teehnology  and  trends  in  the  IS  marketplace. 

— >  Goal  5:  Synchronize  IMA  actions  within  TRADOC 

TRADOC  will  foster  the  total  system  fielding  concept  to  implement  IS  modernization. 
Implementation  of  solutions  must  consider  the  total  defined  requirement.  TRADOC  will  define  and  use 
the  least  disruptive  evolutionary  growth  strategy  when  resources  constrain  fielding  complete  solutions. 
TRADOC  must  coordinate  the  delivery  of  IS  components  to  achieve  initial  operating  capability  as  early 
as  possible  for  each  modernization  action  and  to  minimize  downtime  during  modernization  cut-overs. 
TRADOC  must  identify  synergistic  opportunities  among  disparate  modernization  programs.  TRADOC 
must  minimize  pro^am  managers'  "stove-pipe"  approach  in  development  and  fielding  actions  that  affect 
TRADOC  installations.  DCSEM,  in  coordination  with  HQ  functional  staff,  must  document  pending  IMA 
actions  so  that  TRADOC  DOIMs  are  aware  of  external  agencies'  plans  for  their  installations.  HQ 
TRADOC  staff  must  coordinate  with  external  agencies  to  resolve  issues  identified  by  DOIMs. 

->  Goal  6:  Design  appropriate  IMA  organizations  across  TRADOC 

TRADOC  must  ensure  its  organizations  are  tasked,  designed,  staffed,  and  funded  to  provide 
effective  and  efficient  IM  services  and  ensure  its  organizations  have  expeditious  access  to  external  talent 
(e.g.,  contractors.  Defense  Printing  Service,  Communications  and  Electronics  Command  (CECOM)). 

1.4  TPRISM  Organization 

This  document  is  one  part  of  the  TRADOC  Plan  for  Reengineering  Information  Systems 
Modernization  (TPRISM).  It  is  the  command  level  architectural  framework  document,  DoD's 
recommended  first  step  toward  standards  based  planning  in  the  information  mission  area  (IMA).  It  is 
supported  by  more  dynamically  changing  displays  accessible  through  DCSIM's  homepage  on  the 
Internet.  For  example,  a  graphic  database  tracks  characteristics  of  the  command's  system  architecture  at 
the  installation  level  and  Gantt  charts  display  the  timelines  for  known  IMA  modernization  actions. 

For  more  information: 

http://www-tradoc.monroe.armv.mil/netviz/index.html 

http :/ /www-tradoc.monroe.  armv.mil/netviz/svncmatrix/indey  htm  1 


6 


Figure  1  depicts  how  this  document  is  organized.  Following  the  siimmary  in  this  chapter,  Chapter  2 
amplifies  the  context  for  TRADOC's  IS  modernization  planning.  It  will  help  resource  and  requirements 
managers  and  installations  understand  DCSIM's  management  approach  and  goals  for  IS  modernization. 

Chapter  3  provides  architectural  principles.  Since  TPRISM  cannot  anticipate  or  discuss  all 
decisions  needed  to  modernize  the  command's  IS  components,  the  principles  provide  general  guidance  to 
help  make  specific  decisions  consistently  with  the  command's  architectural  fi'amework.  This  chapter 
provides  guidance  to  external  program  managers  on  TRADOC's  expectations  for  successfully  inserting 
systems  into  TRADOC  installations;  and  it  provides  installations  and  functional  proponents  guidance  on 
the  characteristics  DCSIM  is  looking  for  in  modernization  proposals. 

Chapter  4  looks  at  TRADOC's  IS  environment  from  several  viewpoints: 
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•  operational  architecture  (how  mission  affects  information  requirements) 

•  architecture  (what  standards  must  be  observed  for  IS  modernization) 

•  systems  architecture  (what  IS  components  provide  the  baseline  and  objective  IM  capabilities) 

These  viewpoints,  laid  out  in  accordance  with  the  framework  discussed  in  Chapter  2.  provide 
modernization  planners  at  all  levels  (installations,  external  PMs,  and  staff  functional  proponents)  the 
DCSIM's  perspective  on  how  the  command  will  justify,  design,  and  incrementally  field  IS  capabilities.  It 
discusses  the  command's  entire  objective  architecture,  from  common  user  infrastructure  to  mission 
specific  software,  to  help  promote  interoperability  among  all  IS  components  planned  for  insertion  into 
TRADOC  operations. 

Chapter  5  describes  key  modernization  projects  aimed  at  advancing  our  IS  toward  the  objective 
architecture  described  in  Chapter  4.  It  also  provides  an  overview  of  resources  ^d  organizational 
responsibilities  for  modernization  projects.  It  will  help  installations  and  activities  understand  projects 
that  affect  their  IS  architectures  and  identify  opportunities  for  leveraging  others'  efforts. 

TPRISM's  appendices  provide  detailed  information  about  standards,  the  command's  baseline 
system  architecture,  mission  applications  and  acronyms. 


Chapter  Two:  TRADOC's  IS  Planning  Context 

This  chapter  introduces  themes  used  throughout  TPRISM  as  the  foundation  for  its  content  and  the 
framework  for  its  organization.  These  themes  provide  a  consistent  context  to  analyze  TRADOC's  IS 
environment  and  plan  its  modernization. 

2.1  Architecture  Framework 

In  executing  IS  modernization  efforts,  TRADOC  is  migrating  toward  an  open,  stand^ds  based, 
architecture.  This  approach  will  best  create  the  flexible  and  robust  features  and  connectivity  required  to 
execute  our  mission.  TRADOC's  resource  constraints  preclude  investments  in  large,  single  vendor 
solutions,  acquired  centrally  at  one  time,  with  all  interfaces  already  designed,  engineered  and 
standardized  by  the  vendor.  TRADOC  must  harness  many  smaller  acquisitions  by  installations, 
functional  proponents,  and  external  activities  into  a  command-wide  information  capability,  with 
assurance  that  components  can  interoperate  and  exchange  information.  To  do  so  requires  adherence  to 
technical  standards  and  consistent  architectural  principles,  executed  through  many  decentralized 
decisions.  An  open  systems  architecture  will  improve  TRADOC's  ability  to; 

•  Interface  heterogeneous  vendors'  systems 

•  Execute  information  technology  insertions 

•  Exchange  information  within  TRADOC  and  with  external  activities 

•  Create  a  consistent  user  interface  across  the  command 

•  Contract  for  maintenance,  supplies  and  training 

•  Reuse  components  in  different  environments 

•  Grow  or  change  IS  components  as  TRADOC  grows  or  changes 

•  Create  common  security  policy  and  support  services 

The  key  concepts  of  this  architectural  approach  are  discussed  below. 

2.1.1  Standards  Based 

TRADOC  is  migrating  to  an  IS  architecture  composed  of  open  systems.  This  builds  on  the  joint 
staffs  vision  of  an  infosphere,  into  which  users  can  plug  a  variety  of  IS,  regardless  of  where  they  are, 
and  begin  immediately  to  push  and  pull  information.  An  open  systems  environment  is  not  a  particular 
automation  or  telecommimications  topology  nor  a  set  of  particular  vendor  products.  In  an  open  systems 
environment,  the  designers  implement  published,  or  non-proprietary,  standards  for  interfaces,  services 


8 


and  infonnation  formats  (e.g.,  data  elements,  messages)  to  enable  properly  engineered  components  to 
interoperate  with  other  components. 

TRADOC  aims  for  joint  interoperability  by  observing  a  hierarchy  of  standards  profiles.  The 
hierarchy  starts  with  the  Joint  Technical  Architecture  (JTA)  and  the  JTA-  Army  (formerly  Army 
Technical  Architecture  (ATA)).  Where  those  profiles  permit  choices,  or  fall  short  of  the  level  of 
standardization  TRADOC  requires,  then  TRADOC  augments  them  to  meet  the  command's 
interoperability  requirements. 

Mandating  use  of  open  standards  is  not  sufficient  in  itself  to  ensure  interoperability.  Components, 
even  if  compliant  with  open  standards,  do  not  necessarily  directly  interface.  There  are  still 
implementation  choices  to  be  made.  TRADOC  will  refine  its  standards  profile  as  applicable  to  the 
particular  set  of  components  in  our  system  architecture  and  enforce  command  wide  compliance  in 
acquisition  decisions.  However,  the  intent  is  to  standardize  on  "standards,"  not  on  systems.  That  is, 
TRADOC  will  tolerate  various  vendors'  systems  as  part  of  the  architecture  as  long  as  they  conform  to 
the  applicable  standards,  rather  than  demanding  installations  use  a  particular  vendor's  products  to  ensure 
interoperability. 

If  the  JTA-Armv  and  industry  standards  are  insufficient  to  enable  heterogeneous  systems  to 
interface  sufficiently  to  implement  a  required  command-wide  capability,  then  selection  of  a  product  may 
become  necessary  for  implementing  a  specific  capability. 

There  will  be  some  further  narrowing  of  choice  through  other  processes,  e.g.,  the  use  of  preexisting 
IDIQ  contract  products  and  DMS  compliance.  Also,  since  installation  Directors  of  Information 
Management  (DOIMs)  cannot  provide  maintenance  and  training  support  for  all  vendor  products,  they 
may  promulgate  preferred  products  lists  and  restrict  their  support  to  the  preferred  products.  However,  in 
establishing  levels  of  support,  installations  will  not  be  so  restrictive  as  to  preclude  use  of  WAN  or  CAN 
assets  by  any  JTA-Armv  compliant  IS.  TRADOC  organizations  may  deviate  from  preferred  products 
lists,  but  doing  so  risks  loss  of  compatibility  with  other  TRADOC  systems  and  reduced  DOIM  capability 
to  support  the  non  preferred  product.  To  assist  DOIMs  in  enforcing  this  approach,  TRADOC  CofS 
issued  a  memorandum,  15  Aug  97,  stating  the  coordinated  command- wide  preferred  products  for 
hardware  and  software  at  the  personal  level.  The  memo  included  product  configurations,  reproduced  in 
paragraph  4.4.2. 5  (hardware)  and  4.4.3.2  (software),  which  are  supported  by  TRADOC  DOIMs  for 
FY98. 

See  also: 

Appendix  A:  TRADOC's  Technical  Architecture  Standards 

2.1.2  Multiple  Levels 

IS  are  employed  and  integrated  at  various  organizational  levels.  TRADOC's  organizational  levels 
include  the  personal,  local  (office  or  building),  installation,  mission  and  MACOM  (or  enterprise).  So,  for 
example,  networks  run  at  the  local  (i.e.,  LANs),  installation  (i.e.,  CANs),  mission  (e.g.,  DISN  Enhanced 
IP  Services  for  M&S)  and  enterprise  (e.g..  Defense  Information  System  Network  (DISN))  levels.  This 
matrix  of  IS  components  and  organizational  levels  impacts  TRADOC's  modernization  planning  in  two 
important  ways,  evident  throughout  TPRISM: 

•  IS  components  (networks,  platforms,  applications)  employed  within  each  level  (personal,  local, 
installation,  mission,  MACOM)  must  be  integrated  to  support  mission  execution  at  that  level. 

•  IS  components  must  be  sufficiently  integrated  among  the  levels  to  achieve  the  interaction  required 
for  executing  the  command's  mission. 

2.1.3  Multiple  Viewpoints 

Architectures  provide  a  framework  for  portrajdng  the  relationships  among  all  entities  of  a  complex 
system.  DoD  and  Army  guidance  for  defining  architectures  includes  three  viewpoints:  operational, 
technical  and  systems.  Each  portrays  different  types  of  entities  and  relationships,  as  illustrated  in  Figure 
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2.  A  complete  set  of  these  architectural  viewpoints  for  TRADOC  will  provide  a  comprehensive 
understanding  of  the  IS  components  required  and  planned  to  achieve  interoperable  capabilities 
throughout  the  command. 

For  more  information: 

httD://www.cisa.osd.mil/cisa/itfhoDass/archfwk.ndf 

2.1.4  DoD  Technical  Reference  Model 

DoD  has  further  refined  the  methodology  for  organizing  IS  architectmes  with  its  Technical 
Reference  Model  (TRM),  described  in  the  Technical  Architecture  Framework  for  Information 
Management  (TAFIM).  Since  TPRISM  uses  the  TRM  to  organize  several  sections,  understanding  it  will 
help  to  keep  the  reader  oriented.  Figure  3  shows  the  DoD  TRM,  with  some  adaptations  (italicized  labels) 
for  the  TRADOC  context.  These  added  category  labels  should  not  be  assumed  to  be  comprehensive  or 
static.  TRADOC  will  migrate  to  specific  system  components  that  fit,  functionally  and  technically,  into 
this  framework. 

For  more  information: 

httD://www-librarv.itsi.disa.mil/tafim/tafim3.0/pages/tafim.htm 
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Aroh^BcUrB:  A  framework  that  portrays 
relationships  among  the  elements  in  its  view. 
Army  uses  three  viewpoints  for  information. 


Teeftmcait  Relationships  among 
engineering  standards  used  to 
build  information  products  and 
systems. 


OperaSonat  Relationships  among 
missions,  functions,  information  and 
organizations. 


Swfem:  Relationships  among  the 
systems  (processors,  software, 
communications)  and  organizations. 


Figure  2.  Army’s  C4  architecture  viewpoints 


11 


Mission  Applications 

Examples: 

Computer  Based  Instruction  and  ether  training  applications 
Janus,  CCTT  end  other  M&S  applications 
Management  Information  Systems,  ST  AMIS 


API 


Platfomis 


API 


Support  Applications 


Comm- 

Business 

Enuironment 

Database 

Engineer 

uniQlion 

processng 

Mgt 

unities 

Support 

DVIC 

as 

0(t-lfneltep 

Qn&ies 

■■■■ 

Syste  m  Support  Seivice  s 

User 

Interface 

Data 

Mgt 

Graphics 

Services 

Data 

Inter¬ 

change 

Network 

Services 

Operating  System  Senfices 


Hardware 


External 

Environment 


Communication  Networks 

(WAN/C  AN^AN) 


External 

Processors  &  Data 


Users 


Figure  3.  Technical  reference  model 
2.1.4.1  External  Environment  Layer 

At  the  foundation  of  the  TRM  (Figure  3).  is  the  external  environment.  It  is  similar  to  what  the  joint 
staff  calls  the  "infosphere"  in  their  concept,  C4I  for  the  Warrior,  in  that  it  is  everything  an  IS  can  plug 
into  to  perform  its  own  mission.  It  encompasses  external  data  stores  and  the  networking  that  accesses 
them.  Networks  will  be  integrated  at  several  levels,  but  all  levels  will  interface  sufficiently  to  support  the 
seamlessly  electronic  flow  of  information  that  TRADOC's  mission  requires.  Networking  components 
occur  at  various  levels,  to  include  LANs  that  support  buildings;  CANs,  or  the  backbone  that  connects  an 
installation's  LANs;  and  WANs  to  support  command-  wide,  inter-installation  information  transfer. 
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WANs  will  generally  be  provided  by  access  to  commercial,  federal  or  DoD  networks.  Interfaces  among 
the  networks  will  ensure  both  unstructured  data,  e.g.,  voice  and  e-mail,  and  structured  data,  e.g., 
computer  graphic  files  and  video  images,  can  be  transported  command-wide  with  minimal  demands 
placed  upon  the  users. 

2.1.4.2  Platforms  Layer 

At  the  next  layer  of  the  TRM  are  the  computing  platforms,  which  encompass  the  hardware,  the 
operating  systems  software  that  provides  hardware  with  its  basic  capabilities,  and  the  system  support 
services  that  provide  fundamental  services,  usually  transparent  to  the  user,  but  relied  upon  by  the  higher 
level  applications.  Platforms  are  employed  at  all  levels  of  TRADOC's  baseline  system  architecture,  but 
the  objective  architecture  emphasizes  the  personal,  local  and  mission  levels.  A  uniform  set  of  platform 
services  will  increase  application  portability  and  system  interoperability  so  that  MACOM  level 
capabilities  can  be  created  using  platforms  employed  at  lower  levels. 

2. 1.4.3  Applications  Layer 

The  top  layer  of  the  TRM  is  applications,  which  is  divided  into  mission  and  support  applications. 
Mission  applications  implement  specific  end  user  requirements  or  functions.  The  Army's  strategy  for 
software  architecture  is  that  applications  will  use  domain  (function)  specific  architectures,  usually 
inte^ated  at  the  mission  level,  with  standard  application  program  interfaces  (APIs)  for  exchanging 
services  and  information  with  other  parts  of  the  architecture.  End  user  requirements  within  a  functional 
area  are  subdivided  further  to  determine  a  manageable  set  of  capabilities  for  inclusion  in  any  specific 
application.  To  help  organize  its  discussion  of  mission  applications,  TPRISM  uses  three  basic  categories 
tfeoughout;  training  applications,  models  and  simulations  (M&S),  and  installation  management 
applications,  which  could  also  be  put  in  the  broader  category  of  management  information  systems 
(MIS).  These  categories  can  be  linked  to  the  key  functions  used  in  the  TRADOC  Stratesic  Plan  97.  To 
prepare  the  Army  for  war,  TRADOC  relies  primarily  on  training  applications  and  M&S;  to  be  the 
architect  of  the  future,  TRADOC  relies  on  primarily  on  M&S;  and  to  ensure  TRADOC's  own 
capabilities  requires  use  of  MIS. 

Support  applications  are  common  applications  that  can  be  standardized  across  all  functional  areas. 
Specific  support  applications  are  domain  independent,  i.e.,  they  provide  basic  capabilities  that  satisfy 
requirements  that  remain  the  same  for  all  functional  areas.  Examples  include  e-mail,  distributed 
conferencing  and  database  managers.  The  DoD  TRM  uses  six  support  application  categories: 
multimedia;  communications;  business  processing;  environment  management;  database  utilities;  and 
engineering  support.  Figure  3  is  a  modified  subset  that  makes  the  application  categories  more  obviously 
applicable  to  TRADOC.  Almost  by  definition,  support  applications  are  integrated  at  the  MACOM  or 
enterprise  level  in  order  to  work  across  functional  domains. 

2.2  Strategic  Goals  for  IM 

TRADOC's  IMA  planning  is  focused  on  the  goals  discussed  in  the  subparagraphs  that  follow.  The 
overall  intent  of  each  goal  was  defined  in  paragraph  1.3.3.  Each  goal  description  below  includes  the 
DCSIM's  implementation  strategies  for  achieving  it. 

2.2.1  Improve  interoperability  of  TRADOC's  IS 

Develop  baseline  assessment 

Complete  and  maintain  accuracy  of  TPRISM  system  architecture  database  and  display  for  each 
TRADOC  installation. 

Develop  preferred  products  lists  for  command-wide  use 

Define,  obtain  required  approvals,  and  publish  preferred  products  lists  to  include  such  key  capabilities  as 
e-mail,  word  processing,  graphics,  project  management,  web  browser,  spreadsheets,  multi-media 
authoring  system  and  operating  system. 
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Proliferate  preferred  products  as  widely  and  quickly  as  possible 

Determine  and  execute  actions  within  the  DCSIM's  authority  and  means  to  increase  the  use  of  products 
off  the  preferred  products  lists  throughout  TRADOC  (e.g.,  resourcing  priorities,  approvals,  centralized 
acquisition,  technical  assistance  with  command- wide  interfacing).  Define  and  seek  additionally  required 
means  if  necessary. 

Ensure  IMSC  reviews  systems  for  JTA-Army  compliance 

Define  and  implement  a  procedure  to  ensure  IMSC  reviews  include  consideration  of  JTA-Army 
compliance  for  each  project  reviewed.  Define  and  implement  a  procedure,  within  DCSIM  means,  for 
developing  staff  recommendations  to  IMSC  regarding  technical  issues  of  JTA-Army  compliance.  Define 
and  seek  additionally  required  means  (e.g.,  contract  fiinds,  training  or  staffing)  as  necessary. 

Employ  common  user  networks  as  first  priority 

Determine  and  execute  actions  within  the  DCSIM's  authority  and  means  to  increase  TRADOC's  use  of 
common  user  networks  vice  dedicated  circuits. 

Manage  TRADOC  Project  Change  of  Century 

Manage  TRADOC  efforts  to  ensure  all  mission-critical  automated  systems  and  infrastructure  operate 
properly  after  the  Year  2000  (Y2K). 

2.2.2  Modernize  IMA  infrastructure 

Identify  and  obtain  funding  from  all  available  sources 

Identify  any/all  sources  of  funds  with  potential  for  increasing  the  overall  budget  available  for  IMA 
infrastructure  modernization.  Expand  DCSIM's  competition  for  funds  across  the  Headquarters  and  at 
HQDA,  OSD  levels,  as  necessary.  Improve  TRADOC's  success  in  competing  for  external  funding  of  our 
IS  infrastructure  modernization  (e.g.,  PPC4I).  Improve  success  of  information  management  in 
competing  for  internal  TRADOC  Ending  (e.g.,  KEI,  Bold  Grant,  NPR  seed  funding,  etc.),  and  in 
obtaining  a  share  of  functional  funds  proportional  to  the  impact  on  infrastructure  (e.g..  Army  Distance 
Learning). 

Bypass  technology  stages  whenever  affordable 

Analyze  strategy  of  projects  within  DCSIM's  visibility  to  ensure  DCSIM's  objective  architecture,  vice  an 
interim  target  architecture,  is  being  plaimed  for  implementation.  Analyze  economics  of  using  DCSIM's 
objective  architecture  whenever  an  interim  architecture  is  being  planned.  Execute  actions  within  the 
DCSIM's  means  and  authority  to  ensure  the  objective  architecture  is  fielded. 

Influence  national  networks  to  ensure  TRADOC's  requirements  are  met 

Determine,  promote,  and  execute  actions  within  DCSIM's  visibility,  means  and  authority  for  influencing 
the  managers  of  national  networks  to  satisfy  TRADOC's  requirements. 

Eliminate  gaps  in  CAN  connectivity 

Determine  the  minimal  coimectivity  requirements  that  all  TRADOC  installation  CANs  must  support. 
Determine  and  execute  actions  within  DCSIM's  visibility,  means  and  authority  to  eliminate  the  gaps  in 
capability.  Define  and  seek  additionally  required  funding  and  means  as  necessary. 

Implement  mainframe  life  cycle  replacement. 

Implement  the  approved  course  of  action  for  eliminating  the  existing  mainframes  from  installations' 
infrastructure,  while  continuing  to  modernize  still  required  capabilities  (ASIMS  front  end  processing  and 
remote  job  entry). 

2.2.3  Improve  the  process  for  managing  IMA  requirements 
Develop  a  process  for  requirements  management 

Determine  existing  processes/procedures  and  policies  governing  identification  of  IM  requirements 
within  TRADOC.  Define  procedures  for  managing  all  types  of  IMA  requirements  with  consistency  and 
continuity  across  DCSIM.  Define  DCSIM's  role  in  executing  TRADOC's  Army- wide  requirements 
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management  responsibilities,  and  integrate  DCSIM  promulgated  procedures  with  Army-wide 
procedures.  Justify  rmfinanced  requirements  with  a  solidly  defined  and  analyzed  set  of  information 
technology  requirements. 

Create  internal  visibility  for  DCSIM  requirements  and  projects 

Define  the  procedures  and  develop  the  means  for  ODCSIM  leadership  to  review  requirements  and 
project  status  and  to  stay  abreast  of  issues  appropriate  for  their  level  of  attention.  Institutionalize  among 
DCSIM  staff  the  practice  of  obtaining  and  displaying  the  information  required  for  issue  identification. 
Define  and  seek  additionally  required  means  as  necessary  to  implement  the  procedures. 

2.2.4  Incorporate  information  technology  into  TRADOC  business  processes 

Obtain  and  publicize  knowledge  of  current  and  emerging  technologies 

Determine  the  actions  and  means  required  for  making  ODCSIM  a  well  known  and  used  source  of 
knowledge  about  current  and  emerging  technologies  relevant  to  functional  staffs  requirements. 
Implement  actions  within  the  DCSIM's  means  and  define  and  seek  other  means  as  necessary. 

Institutionalize  the  comparison  of  current  processes  with  technology 

Determine  and  implement  a  process  to  routinely  alert  functional  staff  about  opportunities  made  possible 
through  technology  insertion  and  to  inject  DCSIM  knowledge  about  current  and  emerging  technologies 
into  staffs  on-going  analyses  and  plans  for  functional  improvements. 

2.2.5  Synchronize  IMA  actions  within  TRADOC 
Improve  the  process’  visibility,  display  and  credibility 

Evolve  the  procedure  that  generates  the  DCSIM  synchronization  matrix.  Increase  the  visibility  among 
DCSIM  staff  of  its  data.  Improve  the  value  to  DCSIM  management  of  the  Conference  Room  display 
(alert  them  to  issues  requiring  their  attention.)  Improve  the  timeliness  of  the  database  and  display. 
Improve  the  credibility  of  the  data— its  identification  of  synchronization  issues  and  its  timeliness,  breadth 
and  depth. 

Obtain  data  on  planned  IS  fieldings 

Define  and  implement  reliable  procedures  for  obtaining  data  on  a  timely  basis  regarding  fielding  of  IS 
on  TRADOC  installations,  by  any  activity  internal  or  external  to  TRADOC.  implementation  issues.  Data 
includes  locations,  schedules  responsibilities  and  known  implementation  issues. 

Place  fielding  schedules  on  DCSIM  home  page 

Load  data  obtained  about  fielding  schedules  and  synchronization  issues  on  the  DCSIM  home  page,  and 
provide  a  capability  to  search  by  system,  installation  or  time  period. 

Coordinate  solution  to  synchronization  issues  whenever  possible  and  needed 

DCSIM  staff  will  get  involved  in  resolving  known  synchronization  issues.  When  solution  lies  outside 
DCSIM's  authority  or  means,  staff  will  coordinate  the  identification  and  implementation  of  solutions 
with  the  affected  activities.  Staff  will  continuously  cultivate  points  of  contact  in  external  activities. 

2.2.6  Design  appropriate  IMA  organizations  across  TRADOC 

Conduct  an  IPT  with  DCSIM  and  DOIMs  to  develop  organizational  options 

Using  an  integrated  process  team  (IPT)  approach,  DCSIM  will  organize  and  execute  an  effort  to  develop 
alternatives  for  supporting  the  command's  increased  reliance  on  information  technology  with  decreasing 
resources.  IPT  will  use  the  expertise  of  cluster  center  DOIMs. 

Survey  best  practices  of  external  organizations 

Survey  other  Army  MACOMs,  the  Air  Force  and  large  corporations  on  their  current  IMA  planning  and 
operations  organization.  Define  opportunities  for  reengineering  TRADOC's  organizations  in  line  with 
the  best  practices  identified. 


15 


Execute  staff  development 

Successful  implementation  of  these  strategies  relies  on  informed  and  technically  competent  DC  SIM  staff 
members.  DCSIM  management  team  will  execute  staff  development  with  aim  of  helping  staff 
understand  DCSIM's  strategic  direction  and  their  role  in  its  achievement,  and  developing  competencies 
required  to  execute  their  role. 

2.3  Outcome  Monitoring 

Table  2  provides  the  key  outcome  measurements  that  DCSIM  will  use  to  gauge  progress  toward  the 
above  goals 

Table  2.  Outcome  measurements _ 

ILong  term  trend:  100%  of  new  IS  are  based  on  an  open  architecture  compliant  with  JTA-Army  I 
standards. 

Short  term  measure:  Same. 

Long  term  trend:  100%  of  currently  employed  IS  that  use  a  proprietary  architecture  are  migrated 
to  JTA-Army  compliant  IS. 

Short  term  measure:  None.  Achieve  within  HQDA  target  for  installation  systems:  2006. 

Long  term  trend:  100%  of  TRADOC  employees  have  adequate  DMS  capability. 

Short  term  measure:  None-need  to  clarify  specific  goals  for  individual  users. 

Long  term  trend:  100%  of  voice  and  data  transport  requirements  met 

Short  term  measure:  100%  of  requirements  for  core  MACOM  competencies  (i.e.,  training, 

combat  developments  and  doctrine),  except  for  video  teletraining  and  simulation  by  1998. 

Long  term  trend:  Definition  of  impact  on  infrastructure,  used  to  decide  system  approvals,  is 
sufficiently  accurate  and  comprehensive  to  preclude  implementation  issues. 

Short  term  measure:  100%  of  TRADOC  requirements  packages  will  project  the  impact  on 
TRADOC's  information  infrastructure  prior  to  approval. 

Long  term  trend:  Mix  of  IS  investments  optimizes  architectural  capabilities  and  return  on 
investment. 

Short  term  measure:  100%  of  on-going  IS  projects,  i.e.,  as  visible  at  DCSIM  level,  have 
complied  with  the  DCSIM  requirements  management  process  for  analysis,  prioritization  and 
approval. 

Short  term  measure:  DCSIM/DOIMs'  recommendations  on  technolo^  insertion  are  included  in 
100%  of  the  known  process  reengineering  projects  conducted  by  functional  proponents. 

Long  term  trend:  100%  of  IS  fielding  actions  are  synchronized. 

Short  term  measure:  100%  of  IS  insertions  conducted  at  TRADOC  installations  have  prior 
DCSIM/DOIM  coordination. 

Short  term  measure:  All  fielding  actions  are  executed  without  adverse  effect  of  one  action  upon 
another,  as  measured  by  implementation  feedback  visible  at  DCSIM  level. 


Chapter  Three:  TRADOC's  Architecture  Principles 

Architecture  principles  are  the  foundation  of  a  standards-based  architecture.  They  are  necessary  to 
achieve  the  organizational  consensus  required  to  move  ahead  with  a  command  wide,  standards-based 
architecture.  This  set  of  architecture  principles  sets  the  direction  on  how  TRADOC  will  use  information 
technology  in  the  next  5  to  10  years.  These  principles  establish  a  context  for  architecture  decisions  made 
throughout  the  command. 
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3.1  Apply  total  systems  fielding  concept 

TRADOC  does  not  accept  standard  (i.e.,  mandatory  use)  systems  from  external  program  managers 
prior  to  obtaining,  or  mutually  planning  the  migration  of,  the  infrastructure  that  is  necessary  to  attain 
operational  capability.  TRADOC  does  not  invest  its  own  resources  in  IS  without  obtaining  all 
components  for  a  useful  operational  capability.  TRADOC  does  not  invest  in  the  highly  visible  user 
application  components  of  systems  while  neglecting  the  less  visible,  common  user  infrastructure. 

3.2  Orchestrate  modernization  actions 

TRADOC  coordinates  the  delivery  of  IS  components  to  achieve  initial  operating  capability  as  early 
as  possible  for  each  modernization  action  and  to  minimize  downtime  during  modernization  cut-overs. 
TRADOC  identifies  synergistic  opportunities  among  disparate  modernization  programs.  TRADOC 
functional  proponents  minimize  the  "stove-pipe"  approach  in  developing  and  fielding  IS  for  improving 
their  processes.  HQ  TRADOC  tracks  and  publicizes  pending  IS  actions  so  that  TRADOC  DOIMs  are 
aware  of  external  agencies'  plans  affecting  their  installations.  HQ  TRADOC  coordinates  with  external 
agencies  to  resolve  issues  identified  by  DOIMs. 

3.3  Manage  key  investments 

IS  modernization  efforts  are  managed  as  investments.  Within  their  cost  threshold  authority,  HQ 
TRADOC  and  installations  will  consider  the  return  versus  the  risk  in  the  approval  and  resourcing  of 
individual  modernization  projects.  In  considering  projects  for  approval  and  resourcing,  the  review 
criteria  include: 

•  Mission  Impact.  How  will  the  IS  investment  support  improved  performance  in  specific 
outcome-oriented  terms?  Will  it  provide  a  new  capability  or  enhance  current  capabilities?  Is  it 
mandated  by  law  or  executive  directive?  Is  it  required  for  mission-critical  functions?  What  is  the 
expected  magnitude  of  the  improvement  in  performance? 

•  Consistency  with  Vision.  Does  the  project  provide  a  capability  that  is  expected  to  remain  a  useful 
component  of  the  objective  operational  and  system  architecture? 

•  Return  on  Investment  (ROI).  Is  the  calculated  ROI  within  expectations  and  analytically  sound? 

•  Modularity.  Is  the  project  properly  bounded,  or  segmented,  to  enhance  executability  and  minimize 
risk? 

•  Technical  Risk.  Can  the  proposed  technology  be  integrated  with  existing  systems  and  the 
infrastructure?  Does  the  project  take  advantage  of  proven  commercial-off-the-shelf  (COTS) 
products?  How  complex  is  the  system  architecture  and  software  design? 

•  Investment  Risk.  Is  the  proposed  IS  investment  affordable,  particularly  in  comparison  to  the 
overall  IS  budget?  Will  the  investment  require  future  operational  expenditures  that  are  not 
affordable? 

•  Organizational  Impact.  Is  the  organization  ready  for  the  structural  and  procedural  impacts  of  the 
investment? 

3.4  Use  open  standards 

TRADOC's  standards  profile  is  based  on  open  standards.  This  is  consistent  with  the  Army's 
approach  in  the  JTA-Armv.  For  IS  capabilities  where  open  standards  have  matured  sufficiently  to 
control  interoperability,  TRADOC  will  use  the  standards  to  promote  interoperability,  rather  than 
mandate  vendor  specific  products.  However,  TRADOC  will  use  preferred  products  lists  as  necessary  to 
alert  users  about  which  products  will  have  DOIM  support  for  maintenance,  operations,  training,  etc. 
Although  standardization  on  a  product  often  appears  easier  than  using  heterogeneous  products  that 
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confomi  to  open  standards,  TRADOC  adopts  this  approach  since  it  is  consistent  with  legal  and 
regulatory  requirements;  is  consistent  with  the  underlying  TRADOC  objective  to  create  an  open  system 
environment  that  supports  portable,  scaleable,  and  interoperable  applications;  and  leaves  our  architecture 
more  open  for  new  technology  insertions  as  the  marketplace  changes. 

3.5  Execute  distributed  responsibilities 

IS  are  peiyasive  in  TRADOC.  Many  organizations  play  a  role.  Taskings  must  be  clear  to  ensure 
collective  decision  making  results  in  effective  information  management. 

3.5.1  Command  standardization 

For  IS  components'  capabilities  that  are  integrated  at  the  enterprise  and  mission  levels,  HQ 
TRADOC  enforces  compliance  with  TRADOC's  technical  architectme.  This  means  that  some 
characteristics  of  components,  or  sysXQms,  fielded  at  the  installation,  local  and  personal  levels  are  subject 
to  TRj^OC  command-wide  standards.  Enforcement  will  be  exercised  via  requirements  approval  and 
prioritization,  resourcing  decisions  and  acquisition  approvals.  TRADOC's  standards  profile  will  be 
consistent  with  Army  selected  standards,  as  published  in  the  Joint  Technical  Architecture-Armv 
(JTA-Armv).  augmented  and  tailored  as  required  for  TRADOC's  mission.  Further  information  on 
TRADOC's  standards  profile  is  in  Appendix  A. 

3.5.2  Installation  standardization 

For  IS  capabilities  that  are  integrated  at  the  installation,  building  or  personal  levels,  installations 
enforce  compliance  with  the  installation's  technical  architecture.  Adopt  installation  standards  profiles 
that  ensme  seamless  interfaces  between  the  installation/building/personal  levels  and  the 
enterprise/mission  levels.  ("Seamless"  means  the  interfaces  permit  continuous  electronic  transport  of 
infomation  through  any  combination  of  networks  and  platforms  in  a  manner  that  is  transparent  to  the 
application  and  the  user.  Seamlessness  is  achieved  through  use  of  standard  communications  protocols, 
data  interchange  formats,  and  distributed  system  interfaces).  Installation  commanders  are  authorized  to 
develop  lists  of  supported  products  (e.g.,  those  for  which  the  DOIM  will  provide  help  desk  services), 
but,  in  establishing  levels  of  support,  installations  will  not  be  so  restrictive  as  to  preclude  use  of  W./^  or 
CAN  assets  by  any  JTA-Armv  compliant  IS. 

3.5.3  Command-wide  capabilities 

HQ  TRADOC  DCSIM,  in  coordination  with  the  TRADOC  Information  Systems  Security  Program 
Manager  (ISSPM),  leads  implementation  for  networking,  platforms  and  support  applications 
components  that  require  integration  at  the  command  level. 

3.5.4  Mission  level  capabilities 

HQ  TRADOC  staff  elements,  and  assigned  integrating  activities,  manage  implementation  of 
requirements  for  IS  components  and  capabilities  that  are  integrated  at  the  mission  level.  This  includes 
representing  users'  interests  for  DoD/Army  program  manager  systems.  HQ  TRADOC  staff  elements 
conduct  business  process  reengineering  as  necessary  to  analyze  the  value  of  information  technology 
insertions  in  improving  TRADOC's  mission  execution  within  their  areas  of  proponency. 

3.5.5  Installation  capabilities 

Installations  plan  and  implement  capabilities  that  are  integrated  at  the  installation,  building  and 
personal  levels.  DOIMs,  in  coordination  with  the  Installation  ISSMs,  integrate  planning  at  this  level. 

3.6  Maintain  common  user  assets 

The  mix  of  TRADOC  investments  will  include  common  user  networking  and  platforms  that  satisfy 
multiple  missions,  vice  simply  components  designed  for  particular  mission  applications. 
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3.7  Manage  user  interface 

TRADOC  invests  in  IS  components  that  promote  a  common  user  interface  at  the  personal  level 
work  station,  even  if  more  expensive  than  alternative  approaches. 

3.8  Leverage  the  marketplace 

TRADOC  seeks  first  to  satisfy  functional  requirements  using  COTS  and  non-developmental  item 
(NDI)  applications  vice  developing  its  own  high  order  language  applications.  COTS  and  NDI  includes 
both  ready-to-use  applications  (e.g.,  commercial  E-mail  packages  and  Standard  Army  Management 
Information  Systems  (ST AMIS))  and  non-procedural  tool  kits  for  customizing  within  a  set  of 
capabilities  (e.g.,  spreadsheets  and  database  manipulations).  As  necessary,  TRADOC  will  support 
system  application  design,  development  and  maintenance  as  the  Army  proponent  for  training  and 
doetrine.  TRADOC  will  sustain  its  previously  built  applications  until  COTS/NDI  replacement 
components  are  available,  and  as  long  as  resourcing  allows. 
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Chapter  Four;  TRADOC's  IS  Architectures 

This  chapter  looks  at  TRADOC's  IS  architectures  using  several  viewpoints: 

•  operational  architecture  (how  our  mission  affects  our  IS  requirements) 

•  technical  architecture  (what  standards  our  modernization  efforts  must  observe) 

•  system  architecture  (what  components  we  use) 

=>  baseline  (what  we  have  now) 

=>  target  (what  we  know  we  need  to  field  in  the  near  term) 

=>  objeetive  (our  vision  for  what  we  will  use  longer  term) 

4.1  Operational  architecture 

The  major  objective  of  an  operational  architecture  is  to  analyze  the  enterprise's  functions,  processes 
and  organizations  from  the  viewpoint  of  requirements  for  information  exchanges  and  distributed 
information  processing  capabilities. 

4.1.1  TRADOC's  Key  Functions 

As  stated  in  TRAlDOC's  Strategic  Plan  1997.  TRADOC  has  three  key  functions:  prepare  the  Amy 
for  war;  he  the  architect  of  America's  Army  for  the  future;  ensure  TRADOC's  capability  to  execute  its 
mission. 

4.1. 1.1  Prepare  for  war 

Conducting  training  and  leader  development  are  constants  of  TRADOC's  mission  to  prepare  the 
Army  for  war.  Even  as  resources  decline,  the  quality  of  training  provided  by  TRADOC  must  not.  The 
means  and  techniques  will  change  instead.  We  will  invest  in  key  enabling  services  to  support  distance 
learning,  i.e.,  linking  soldiers  and  units  in  the  operating  force  at  locations  distant  from  the  schoolhouse, 
so  that  the  fighting  force  can  be  trained  at  their  home  station  whenever  possible.  We  will  exploit 
education  technologies,  e.g.,  computer  based  instruction,  interactive  and  multimedia  courseware,  and 
training  capabilities  embedded  in  materiel.  We  will  develop  distributive  interactive  simulations,  with 
standardized,  routine  links  among  virtual,  live  and  constructive  simulations.  These  simulation  tools  will 
be  employed  not  only  for  training,  but  for  combat  developments  and  mission  analysis  as  well. 

4.1.1.2  Be  the  Architect  of  the  Future 

As  the  Army's  architect  of  the  future,  TRADOC  must  lead  the  way  in  designing  tomorrow's  Force. 
This  requires  rethinking  all  aspects  of  the  force:  its  operational  concepts,  doctrine,  orgamzation,  skills 
and  equipment.  To  do  so,  TRADOC  requires  new  and  enhanced  capabilities  from  its  IS  architecture. 
TRADOC  cannot  lead  intellectual  change  without  the  right  information  tools  to  support  analysis  of 
alternatives,  especially  via  interconnected  models  and  simulations  (M&S),  and  to  create  Army- wide 
agreement  on  new  concepts. 

4.1. 1.3  Ensure  TRADOC's  own  capabilities 

Efficient  and  effective  command  and  control  and  installation  management  processes  ensure 
TRADOC  has  the  capability  to  execute  its  mission.  This  function  encompasses  personnel,  acquisition, 
resource  management,  supply,  transportation  and  other  functional  areas,  all  of  which  include  numerous 
processes  and  typically  a  hi^  volume  of  transactions.  TRADOC  manages  16  Army  installations  with  2 
million  acres  of  land,  167  million  square  feet  of  facilities,  $8  billion  of  inventory  and  $19  billion  of  real 
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property  replacement  value.  Approximately  157,000  people  work,  train,  and  live  on  TRADOC 
installations.  Twelve  of  the  sixteen  TRADOC  installations  serve  as  laxmch  platforms  to  deploy  soldiers 
beyond  the  borders  of  the  United  States  with  little  advanced  notice.  TRADOC  must  provide  cost 
effective,  responsive,  and  efficient  training  and  readiness  support  and  services  including  ranges,  training 
facilities,  and  training  areas. 

Management  information  systems  help  accomplish  and  coordinate  the  workload.  TRADOC's 
management  functions  are  generally  the  same  as  other  MACOMs'.  This  commonality  permits  HQDA  to 
promulgate  Army  standard  management  IS  for  many  of  these  functions. 

TRADOC  is  seeing  significant  manpower  and  funding  reductions.  TRADOC  must  make  real  the 
platitude,  "Work  smarter,  not  harder"  to  enable  a  reduced  workforce  to  execute  our  mission.  Improved 
information  management  can  help  through: 

•  exchange  of  information  with  external  organizations  working  similar  issues 

•  quick,  efficient  retrieval  and  presentation  of  information  tailored  for  users  ranging  from  CG  to 
action  officers 

•  virtual  collocation  of  command  personnel  for  ad  hoc  problem  solving 

•  efficient  management  of  mission  support  operations 

•  reuse  of  information  content  in  briefings,  concepts,  materiel  requirements,  training  materials,  etc. 

4.1.2  TRADOC's  Key  Processes 

Since  its  creation,  TRADOC  has  executed  several  key  processes  to  implement  its  functions.  TRADOC's 
key  processes  are  doctrine,  training,  combat  developments  and  installation  management.  There  has  been 
some  variation  over  TRADOC's  history,  but  these  are  the  clear  constants,  sometimes  called  TRADOC's 
enduring  domains.  The  start  point  for  an  operational  architecture  is  a  graphic  decomposition,  or  node 
tree,  of  processes.  Figure  4  gives  the  command  level  start  point  for  such  a  node  tree  of  TRADOC's  key 
processes. 
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Figure  4.  Node  Tree  of  TRADOC  Processes 


4.1.3  TRADOC 's  Organization 

TRADOC  is  spread  across  CONUS  on  sixteen  installations.  Installations  host  one  or  more  schools 
and  sometimes  other  analytical  activities.  Schools  have  a  particular  focus  of  expertise,  often  branch 
specific,  and  are  responsible  for  producing  TRADOC  products  within  their  area  of  expertise,  e.g., 
courseware,  materiel  requirements  and  doctrine.  Each  installation  has  a  DOIM,  who  reports  to  the 
garrison  commander.  HQ  TRADOC  staff  includes  several  deputy  chiefs  of  staff  (DCS)  organized  by 
fimctional  areas,  including  proponents  for  each  of  the  core  processes  shown  in  Figure  4  and  the  DCSIM. 
Figure  5  provides  a  depiction  of  the  HQ  staff  and  schools  in  TRADOC. 
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Figure  5.  TRADOC  Organization 


TRADOC's  reengineering  alternatives  include  a  concept  in  which  TRADOC  is  divided  into 
functionally  related  clusters.  Each  cluster  would  have  a  center  that  generated  most  TRADOC  products, 
and  several  related  satellite  schools  that  continue  to  conduct  training.  Centers  and  satellites  would  not 
always  be  collocated  on  one  installation.  The  rationale  for  organizing  into  clusters  is  to  improve  the 
integration  of  products  and  reduce  redundant  procedures  and  staff,  but  the  analysis  to  support  that 
rationale  remains  incomplete.  Even  where  this  particular  reengineering  concept  is  implemented, 
TRADOC  will  remain  a  geographically  distributed  organization  and  dependent  on  electronic  exchange 
of  information. 

For  more  information: 

http://www-tradoc.armv.mil/cmdpubs/97org/table.htm 

4.1.4  TRADOC's  Information  Exchanges 

TRADOC's  distributed  organization  places  high  demands  on  our  information  exchange  capabilities. 
To  ensure  our  products  are  integrated  among  all  branches,  and  that  daily  operations  are  coordinated 
among  our  processes,  TRADOC  must  exchange  information: 

•  horizontally  among  all  installations 

•  vertically  between  HQ  TRADOC  and  all  installations 

•  internally  at  installations,  among  the  activities  developing  TRADOC  products  and  providing 
installation  support 

•  externally,  from  each  TRADOC  installation  to  joint  and  Army  organizations,  including  units, 
HQDA  and  other  MACOMs 

•  externally,  from  each  TRADOC  installation  to  the  civilian  world,  e.g.,  academia  and  industry 

Since  TRADOC  relies  on  process  execution  by  action  officers,  connectivity  must  extend  down  to 
the  personal  level.  In  a  cluster  organization,  more  electronic  exchanges  would  become  supportable  using 
LANs  or  CANS  instead  of  a  WAN,  but  the  action  officer  must  still  have  access  to  all  three  levels  of 
networks.  The  following  paragraphs  discuss  information  exchanges  associated  with  specific  processes. 
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Common  coordination  capabilities  -  TRADOC  relies  on  common  coordination  capabilities  (e.g., 
e-mail  and  file  transfers)  available  at  all  installations  down  to  the  action  officer  level.  TRADOC 
leadership  relies  on  a  robust  desktop  videoteleconference  (DVTC)  network.  Action  officers  rely  on 
access  to  videoteleconference  (VTC)  capabilities,  whether  studio  grade  or  at  the  office  or  desktop  level. 
More  coordination  will  be  done  using  WWW  type  services,  which,  given  requirements  for  protecting 
Army  information,  will  require  both  Internet  and  intranet  connectivity  down  to  the  action  officer  level. 
Coordination  of  TRADOC  products  requires  the  capability  to  move  large  compoimd  files  and  for 
universal  ability  to  read  and  manipulate  the  files.  Increased  use  of  integrated  concept  teams  will  require 
even  more  sophisticated  coordination,  centering  more  on  collaborative  generation  of  products  than  on 
post  coordination  of  them. 

Doctrine  -  TRADOC  is  moving  more  to  electronic  versions  of  its  doctrinal  products-both  for  their 
coordination  and  Aeir  distribution.  TRADOC  also  seeks  to  electronically  push  its  branch  expertise  out  to 
the  area  of  operations  to  augment  commanders'  staff  in  the  development  of  planning  alternatives;  and  to 
capture  lessons  learned  fi’om  on-going  operations  for  future  doctrine  development.  Information 
exchanges  include  world-wide  common  user  coordination  capabilities,  with  emphasis  on  transfers  of 
large  compound  documents  and  interaction  with  units. 

Training  -  A  fundamental  piece  of  reengineering  TRADOC  involves  the  delivery  of  training  using 
IS  capabilities.  Classroom  XXI  will  be  the  focal  point  for  modernizing  institutional  training.  It  will 
incorporate  multi-point  videoteleconferencing,  delivety  of  multimedia  interactive  courseware  and 
eventually  student  participation  in  distributed  simulations  and  distributed  exercises.  As  the  instructional 
method  shifts  fi'om  its  current  instructor  focus  to  a  student  focused  approach,  the  information  exchanges 
will  grow  considerably.  In  student  focused  instruction,  each  student  may  be  using  a  tailored  set  of 
instructional  material,  requiring  connectivity  to  each  student,  rather  than  each  classroom.  There  must  be 
libraries  of  training  materials— not  necessarily  stored  centrally,  but  retrievable  using  one  search  from  the 
users'  viewpoint.  The  system  architectme  must  support  the  instructional  methodology  with  point  to 
point,  multi-point,  high  volume,  real  time,  high  pedk  information  exchange  capabilities. 

Combat  Developments  -  CD  products  are  becoming  more  dynamic.  Emphasis  on  modeling  and 
simulating  concepts,  prototyping  and  experimenting  with  solutions,  and  evolutionary  development  all 
affect  the  degree  and  types  of  information  exchanges.  Integrated  concept  teams  (ICT)  will  bring  together 
skills  from  various  locations  and  disciplines.  Electronic  collocation  will  be  essential  for  helping  the 
teams  work  through  the  processes  involved  in  the  "build  a  little,  test  a  little,  field  a  little"  approach  to 
materiel  development.  Since  much  of  materiel  development  is  aimed  at  information  dominance,  many 
systems  in  development  are  IS.  IS  lend  themselves  to  increased  use  of  simulators  and  rapid  prototypes, 
shared  by  developers  across  the  development  community.  Members  of  ICT  will  also  be  coordinating 
extensively  with  members  of  integrated  product  teams  (IPT)  to  continue  to  represent  the  soldier's  interest 
throughout  the  system  life  cycle.  All  of  this  leads  to  information  exchanges  down  to  the  action  officer 
level  with  widespread  points  internal  and  external  to  the  command.  Content  will  include  VTC  sessions, 
simulation  and  simulator  traffic  and  collaborative  authoring  of  CD  products. 

Installation  management  -  The  characteristics  of  most  information  exchange  requirements  for 
installation  management  are  not  unique  from  those  of  other  Army  installations.  Installation  management 
involves  many  disciplines  and  processes,  e.g.,  supply,  personnel,  financial  management,  facilities 
engineering  and  contracting.  It  includes  processes  for  supporting  power  projection.  Computer  platforms 
are  located  in  a  variety  of  sites  (Defense  Megacenters,  departmental  LANs,  personal  computers). 
Connectivity  must  support  one  time  capture/shared  use  for  data  across  platforms  and  processes.  Data 
transfers  range  from  brief,  interactive  database  query  traffic  to  large  database  transfers.  Connectivity 
must  extend  to  the  point  of  data  collection  and  use.  To  enable  information  exchanges  among  the  many 
processes  and  organizations  involved  in  managing  installations,  connectivity  must  maximize  access  to 
the  common  user  infrastrucUire. 

4.1.5  TRADOC’s  Key  IS  Requirements 

Considering  TRADOC's  key  functions  and  processes,  and  overlaying  its  organization  and 
information  exchanges,  an  overview  of  required  information  processing  capabilities  and  connectivity 
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emerges  (Table  3).  Individual  projects  (see  Chanter  5^  to  realize  these  capabilities  will  specify 
requirements  in  greater  detail,  considering  the  exact  performance  and  output  required  compared  to  the 
local  baseline  architecture. 


Table  3.  Key  IS  Requirements 


TRADOC  Process 

Key  Processing  Capabilities 

Key  Network  Connections 

Doctrine 

Collaborative  authoring 
Document  distribution 

Full  text  retrieval 

Electronic  publishing 

Inter-TRADOC 

Joint  community 

Units 

Training 

Distance  learning  (VTT,  CBI, 
Video) 

Modeling  &  Simulation 
Multimedia  courseware 
development 

Courseware  database 

Inter-TRADOC 

NGB/USAR 

Units 

Combat  Developments 

Modeling  &  Simulations 
Prototype  test  beds 

Collaborative  planning 
Electronic  coordination 

Expert  systems 

Inter-TRADOC 

Joint  commimity 

RD&A  community 

Industry 

Installation  management 

High  transaction  processing 
Large  databases 

Decision  support 

Inter-TRADOC 

Defense  Megacenters 

Common  coordination 

E-mail 

File  transfers 

Office  automation  suites 

VTC  access 

Intemet/Intranet  access 

World-wide 

4.2  Technical  architecture 

Figure  6.  TRADOC  DCG  Memo  on  C4I  Architecture 
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By  implementing  well-defined, 
openly  available  and  consensus-based 
standards,  TRADOC  can  leverage  the 
commercial  marketplace's  investments 
in  new  products  and  assure  a  migration 
path  into  the  future.  TRADOC  will  use 
the  standards  profile  established  in  the 
JTA-Armv.  The  JTA-Army  is  a  set  of 
standards,  applicable  to  information 
processing,  information  transport, 
information  formats,  human-computer 
interfaces  and  information  security. 
The  JTA-Army  applies  to  all  soldier, 
weapon,  and  information  system 
programs,  whether  employed  in  the 
tactical,  strategic,  or  sustaining  base 
environments.  The  applicability  of  the 
JTA-Army  (ATA  at  tiiat  time)  to 
TRADOC  actions  has  been  officially 
recognized  (Figure  6).  The  JTA-Army 
is  based  on  widely  accepted 
commercial  standards  and  implements 
the  mandatory  standards  governing 
interfaces  among  the  services  as 
published  in  the  JTA.  TRADOC  will 
make  permissible  refinements  and 
additions  to  the  JTA-Army  as  required 
to  execute  our  mission  and  maintain 
command-wide  information  flow.  By 
adopting  the  JTA-Army  as  the  guide  for  our  acquisition  decisions,  TRADOC  will  improve  the 
interoperability  of  its  IS  with: 

•  IS  employed  by  other  Army  MACOMs 

•  IS  employed  in  tactical  units 

•  IS  employed  by  other  services  and  DoD  agencies 

•  IS  available  in  the  future  commercial  marketplace. 


Appendix  A  provides  portions  of  the  JTA-Army  and  TRADOC  extensions,  which  are  of  primary 
importance  within  TRADOC  for  technical  architecture  compliance. 

4.3  Baseline  system  architecture 

A  system  architecture  is  the  set  of  specific  system  configurations  designed  to  satisfy  requirements 
identified  in  the  operational  architecture,  within  the  standardization  constraints  imposed  by  the  technical 
architecture.  TRADOC  develops  few  of  its  own  systems.  Most  are  developed  by  DoD  and  Army 
materiel  developers  and  by  commercial  vendors.  Most  of  TRADOC's  system  architecture  effort  is  spent 
integrating  and  configuring  these  components  for  insertion  into  our  baseline  architecture. 

Besides  the  text  description  in  this  chapter,  written  from  the  MACOM  (vice  installation)  viewpoint, 
ODCSIM  also  maintains  a  database  to  portray  selected  aspects  of  installations'  system  architectures.  The 
database  uses  a  graphic  front  end.  Icons  in  the  graphics  are  linked  to  spreadsheets  containing  detailed 
data.  The  ^aphics  that  portray  networks  are  accessible  through  the  DCSIM  homepage.  ODCSIM  can 
provide  printouts  or  electronic  spreadsheets  on  request  for  other  portions  of  the  database.  ODCSIM 
continuously  updates  data  as  changes  become  known  throughout  the  year,  and  conducts  an  annual 
review  of  all  data  with  the  installations.  Installations  should  provide  information  any  time  to  ensure 
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DCSIM's  modernization  decisions  and  justifications  are  based  on  the  most  accurate  data  available. 

The  next  two  sections  provide  an  overview  of  TRADOC's  baseline  and  objective  system 
architectures.  The  baseline  system  architecture  covers  the  IS  TRADOC  relies  on  today  to  execute  its 
mission,  while  the  objective  architecture  portrays  a  vision  for  satisfying  approved  requirements. 
Migration  from  the  baseline  to  the  objective  system  architectiue  will  proceed  in  many  steps  known  as 
target  system  architectmes.  The  following  descriptions  are  organized  according  to  the  layers  of  the  DOD 
Technical  Reference  Model  (TRM)  depicted  in  Figure  3. 

4.3.1  External  Environment 


Mission 

Applications 


Support 

Applications 

Platforms 

External 

Environment 


The  external  environment  is  at  the  base  of  the  TRM.  The  external 
environment  is  anything  outside  the  processing  components  of  a  system.  It  is  the 
aggregation  of  components  through  which  the  information  processor  interacts 
with  Ae  world,  primarily  external  data  sources  and  communication  networks. 


4.3.1. 1  External  data  sources 


Most  individual  IS  in  TRADOC  access  data  from  external  sources.  Analogously,  TRADOC's  total 
system  architecture  relies  heavily  on  data  access,  and  TRADOC  has  IS  components  designed  primarily 
as  data  sources.  Key  examples  are  CAC's  Center  for  Army  Lessons  Learned  (CALL)  database  for 
combat  operations  and  exercises,  and  the  Army  Training  Support  Center's  (ATSC)  Army  Training 
Digital  Library  (ATDL)  for  training  and  doctrinal  products.  Both  are  part  of  the  baseline  architecture, 
but  are  still  early  in  their  system  evolution,  so  TPRISM  discusses  them  more  as  part  of  the  objective 
architecture. 

TRADOC's  school  and  technical  libraries  continue  to  provide  the  command  access  to  external  data 
sources,  including  indexes  to  scientific  and  business  literature,  the  Defense  Technical  Information 
Center,  and  full  text  retrieval  services  such  as  NEXIS.  Increasingly,  the  availability  of  Internet  services 
is  making  access  to  external  knowledge  bases  a  distributed  capability,  available  at  the  action  officer 
level.  Many  action  officers  already  depend  on  IS  capabilities  for  identifying  and  accessing  data  sources 
on  the  Internet,  pushing  and  pulling  information  products  and  manipulating  the  data  pertinent  to 
TRADOC  actions. 

See  also: 

4.4. 1.1  External  data  sources 


For  more  information: 

http://www.atsc-armv.org/atdls.html 

httn://call.armv.mil/call.html 

4.3.1.2  Networks—Enterprise  Level 

TRADOC  relies  on  external  providers  for  the  circuits  in  its  enterprise  level  networks.  Although 
there  are  exceptions  in  the  baseline  system  architecture,  TRADOC  generally  accesses  networks  toough 
federal,  defense  or  Army  management  structures.  There  are  two  broad  categories  of  required  network 
capabilities:  voice  and  data  (including  digitized  images  and  video).  The  baseline  network  architecture 
uses  mostly  separate  components  for  providing  these  capabilities:  telephone  networks  and  data 
distribution  networks.  The  split  is  not  total,  but  the  distinction  is  real. 

For  more  information: 

http  ://www-tradoc.  arm  v.mil/netviz/index.html 
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4.3. 1.2.1  Telephone  Networks 


TRADOC  uses  the  Defense  Switched  Network  (DS^  and  Federal  Telecommunications  System 
(FTS)  as  enterprise  level  voice  networks.  All  TRADOC  installations  have  electronic  switches  for 
accessing  DSN  and  FTS,  provided  by  the  Army's  MACOM  Telephone  Modernization  Program 
(MTMP).  The  Defense  Information  Systems  Agency  (DISA)  manages  the  DSN.  GSA  manages  the  FTS. 
The  DSN  provides  worldwide  imsecured  voice  service  to  military  subscribers.  FTS  provides  imsecured 
voice  service  to  all  points  within  CONUS  that  are  outside  the  DSN,  although  many  DSN  subscribers  are 
also  on  FTS-  including  all  of  TRADOC.  TRADOC's  equivalent  of  FTS  OCONUS  is  International 
Voice  Switched  Service.  FTS  is  the  equivalent  of  obtaining  routine  commercial  service.  DSN  and  FTS 
can  also  be  used  for  circuit  switched  data  services,  and,  via  Secure  Telephone  Unit  (STU)  III 
instruments,  for  secure  conununications. 

4.3.1.2.2  Data  Networks 

For  an  organization  like  TRADOC,  with  fixed  installations  spread  across  CONUS,  the  enterprise 
level  data  networks  are  conunonly  called  WANs.  As  shown  in  Figure  7.  installations  are  typically  linked 
to  several  WAN  segments  which  are  not  necessarily  interconnected  themselves,  nor  connected  in  a 
consistent  manner  with  the  installation's  CAN  or  backbone. 

4.3.1.2.2.1  DISN  Data  Services 

TRADOC  uses  DISA's  worldwide  Defense  Information  Services  Network  (DISN)  as  its  primary 
enterprise  level  WAN  to  connect  TRADOC  installations,  to  connect  to  other  military  sites,  and  to 
provide  Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP)  gateways  to  the  Internet.  DISN 
includes  three  router  network  components  for  data  traffic: 

•  Not  classified  but  sensitive  IP  Router  Network  (NIPRNET)  for  unclassified  traffic 

•  Secret  IP  Router  Network  (SIPRNET)  for  data  up  to  secret  classification 

•  Joint  Worldwide  Intelligence  Communications  Network  (JWICS)  for  top  secret  and  sensitive 
compartmented  information  (SCI) 


See  Appendix  B 
for  examples 


Figure  7.  Baseline  Architecture  for  WANs 


Installations  are  connected  to  the  DISN  through  an  Army  gateway.  The  Army  DISN  Router 
Program  (ADRP)  has  provided  TCP/IP  routers  to  all  TRADOC  installations  for  accessing  the 
NIPRNET. 

The  initial  DISN  started  in  1992.  It  integrated  a  number  of  independent  networks  and  migrated  the 
Defense  Data  Network  (DDN)  to  higher-speed,  router-based  technology.  DISN  circuits  were  provided 
through  the  Defense  Commercial  Telecommunications  Network  (DCTN)  contract,  followed  by  the 
DISN  Transition  Contract  (DTC).  The  DTC  was  replaced  during  1997  by  four  different  contracts  to 
implement  the  DISN  vision. 

Each  DISN  router  network  (i.e.,  NIPRNET,  SIPRNET,  JWICS)  uses  standard  IP  protocols  to  route 
subscribers'  IP  data  packets  across  the  network.  DISN  routers  can  interface  with  several  standardized 
data  link  layers:  Ethernet,  Token  Ring,  Fiber  Distributed  Data  Interface  (FDDI),  and  serial  interfaces 
including  RS-232,  RS-449,  and  V.35.  Serial  interfaces  may  be  used  to  interface  Army  equipment  with 
different  framing  to  include  HDLC,  LAPB,  PPP,  and  X.25.  See  Appendix  A.  paragraph  6.1  regarding 
these  standards. 

Since  fall  of  1995,  DISA  has  been  upgrading  many  DISN  circuits  to  Tls  to  resolve  the  most 
pressing  bandwidth  problems.  But  this  is  only  a  temporary  fix  because  the  network  needs  still  more 
bandwidth.  DISA  is  upgrading  the  DISN  circuits  again  by  installing  a  45 -megabit/sec  asynchronous 
transfer  mode  (ATM)  network  to  directly  connect  core  NIPRNET  routers  in  CONUS.  Direct  connection 
through  this  ATM  backbone  will  bypass  lower-capacity  links  and  inefficient  router  hops.  Long-haul 
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traffic  will  jump  quickly  through  the  ATM  backbone,  then  exit  at  the  NIPRNET  router  closest  to  its 
destination.  Since  DISN  and  its  modernization  stages  will  remain  the  primary  TRADOC  WAN, 
TPRISM  discusses  it  more  thoroughly  as  part  of  the  objective  architecture. 

See  also: 

4.4. 1 .2.2  Data  Network 
5.1.1  DISN 

4.3.1.2.2.2  DISN  Video  Service-Global 

All  TRADOC  installations  have  studio  grade  VTC  facilities.  HQ  TRADOC  centrally  funds  their 
operation.  DCSIM  has  also  fielded  desktop  VTC  (DVTC)  systems  among  the  TRADOC  leadership.  The 
DISN  Video  Service-Global  (DVS-G),  one  of  four  follow  contracts  to  the  DCTN,  provides  continuation 
of  the  high  bandwidth  digital  circuits  required  for  video  traffic,  as  they  have  existed  under  the  DCTN. 
All  TRADOC  studio  and  desktop  VTCs  are  scheduled  to  transition  to  DVS-G  in  1997.  DVS-G  provides 
interoperability  with  FTS2000,  commercial  and  tactical  networks  both  in  CONUS  and  OCONUS. 

Unlike  the  network  provided  under  DCTN,  DVS-G  does  not  provide  DVTC  users  direct  dial  access  to 
FTS2000  and  commercial  AT&T  users.  Coimectivity  to  these  users  is  established  through  a  hub. 

See  also: 

4. 3. 3. 4  Videoteleconferencing 

4.3.1.2.2.3  Automatic  Digital  Network  (AUTODIN) 

AUTODIN  was  established  in  the  1960s  to  meet  the  DoD  operational  requirements  for  a  secure 
messaging  service.  DISA  operates  the  AUTODIN.  It  provides  networking  services  for  all  security 
classification  levels  of  messages.  AUTODIN  is  interconnected  through  a  worldwide  network  of 
store-and-forward  switches.  Other  AUTODIN  components  include  service  and  agency  automated 
message  handling  systems,  terminating  message  facilities  (e.g.,  telecommunications  centers  (TCCs)  and 
special  security  office  (SSO)  message  facilities),  and  routing  and  addressing  directory  databases. 

DISA  has  established  a  schedule  that  closes  the  AUTODIN  by  2000,  and  has  already  closed  three 
of  the  14  AUTODIN  automated  switching  centers  (ASCs).  The  schedule  is  in  synchronization  with  the 
phased  implementation  of  DMS,  the  objective  messaging  system,  operating  over  DISN.  To  prepare  for 
the  shut  down  of  AUTODIN,  TRADOC  has  reorganized  its  networking  architecture  for  messaging  and 
now  uses  the  NIPRNET  and  dial-up  connections  over  STU  Ills  for  much  of  its  traffic.  This  has  involved 
the  establishment  of  TRADOC  Message  Service  Centers  (TMSCs),  located  at  Forts  Gordon, 
Leavenworth  and  Monroe.  Each  provides  centralized  message  distribution  services  to  several  subscriber 
installations  (see  Figure  8).  Only  the  TMSC  remain  directly  connected  to  the  AUTODIN.  All  TRADOC 
TCCs  supported  by  a  TMSC  have  disconnected  their  dedicated  AUTODIN  circuit  and  now  process 
AUTODIN  traffic  as  a  dial-in  subscriber  to  the  ports  on  their  assigned  TMSCs  classified  processing 
terminal.  STU-III  devices  are  employed  for  transmission  security. 

As  use  of  the  AUTODIN  continues  to  decline  approaching  its  elimination,  TRADOC  plans  to 
reduce  the  number  of  TMSCs.  The  remaining  TMSCs  will  provide  service  to  more  installations.  The 
target  is  an  extremely  small  AUTODIN  capability  in  TRADOC  on  the  date  the  AUTODIN  is  replaced 
by  DMS. 

See  also: 

4. 3. 3.2  Messaging 
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DISN 

Dial-Up 


Figure  8.  TMSCs  and  subscribers 


4.3.1.3  Networks—Mission  level 

Since  TRADOC  is  spread  across  CONUS,  networks  employed  to  execute  mission  level  processes 
in  the  command  are  WANs.  Although  the  use  of  dedicated  (stovepipe)  WAN  segments  is  decreasing, 
examples  remain  in  the  baseline  architecture  to  support  various  training,  M&S  and  installation 
management  applications. 

See  also: 

Appendix  B:  Network  Diagrams 

4.3. 1.3.1  Training  Network  (TNET)/Satellite  Education  Network  (SEN) 

TNET  provides  near  full  motion  two-way  video  and  audio,  graphics,  and  computer-based 
teletraining  and  data  transfer  for  courses,  exercises,  after-action  reports,  new  equipment  training,  and 
simulations.  Each  TNET  site  can  send  and  receive  training  from  over  110  other  TNET  locations  and 
over  300  sites  in  other  military  and  state  networks,  including  all  SEN  sites.  It  provides  2  way  384KBS 
video  services.  Other  sites,  including  OCONUS,  can  be  installed  as  training  requirements  dictate. 
TRADOC  has  17  sites  with  access  to  TNET.  Sites  can  be  networked  into  various  combinations.  Army 
Training  Support  Center  has  operational  control  of  TNET.  Sprint  became  the  support  contractor  during 
FY97.  Sprint  replaced  TNET's  previous  satellite  based  network  architecture  with  terrestrial  circuits. 
Sprint  uses  its  nationwide  terrestrial  ATM  network  with  tail  circuits  from  the  closest  Sprint  ATM 
network  point-of-presence  to  TNET  subscribers. 

SEN  is  a  studio-based,  one-way  video  network  with  return  audio  to  the  instructor  over  phone  lines. 
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SEN  broadcasts  a  full  motion  digital  signal  over  three  channels  and  can  also  deliver  analog  broadcasts. 
SEN'S  primary  mission  is  to  support  logistics  and  acquisition  courses  taught  by  the  Army  Logistics 
Management  College  at  the  Defense  Acquisition  University.  SEN  broadcasts  to  61  of  its  own  downlinks, 
40  additional  downlinks  in  the  DAU  network,  and  all  the  TNET  sites  as  well.  SEN  can  also  broadcast  to 
all  Government  Education  Training  Network  and  Governmental  Alliance  for  Training  and  Education 
sites.  TRADOC  has  14  SEN  sites. 

4.3. 1.3.2  Joint  Computer  Based  Instruction  System  (JCBIS) 

JCBIS  is  a  DoD  system,  for  which  TRADOC  is  the  executive  agent.  JCBIS  is  a  network  of 
terminals  providing  access  to  a  library  of  over  10,000  proprietary  and  government  owned  courseware. 
JCBIS  offers  standardized  instruction  that  students  can  study  at  their  own  pace.  The  curricula  includes 
basic  skills,  college  preparation,  job  skills,  high  school  completion  and  college  level  instruction. 

Subjects  include  foreign  languages,  maintenance,  statistics,  electronics,  writing  skills,  management  and 
supervision,  computer  literacy  and  others.  There  is  also  on-line  practical  exercises  and  testing.  There  are 
about  600  terminal  access  points  throughout  CONUS,  connected  via  FTS2000  to  a  mainframe  computer 
at  Fort  Leavenworth.  PCs  are  used  as  the  terminals. 

4.3.1.3.3  DISN  Enhanced  IP  Services 

The  Defense  Simulation  Internet  (DSI)  has  been  a  standalone  network  specifically  designed  for 
operating  distributed  models  and  simulations  among  123  worldwide  organizations.  TRADOC  uses  the 
connectivity  to  link  into  worldwide  distributed  interactive  simulations  $)IS)  to  support  analysis,  combat 
developments  and  training.  TRADOC  subscribers  are  at  Forts  Leavenworth  (2  subscribers:  TRAC  and 
NSC),  Knox,  Rucker,  Benning,  Sill,  Gordon,  Leonard  Wood,  Huachuca,  Eustis,  Lee,  Bliss,  Carlisle 
Barracks  and  TRAC  White  Sands  Missile  Range.  During  CY97,  the  DSI  will  transition  to  the  DISN 
Enhanced  IP  Services  and  in  FY98  the  DSI  will  terminate.  The  replacement  architecture  is  discussed  as 
part  of  the  objective  architecture. 

See  also: 

4.4. 1.3  Networks— Mission  Level 

4. 3. 4.2  Models  and  Simulations  tM&SI 

4.3.1.3.4  Army  Standard  Information  Management  System 

Defense  Megacenters  (DMCs)  host  a  variety  of  standardized  mission  applications,  e.g.,  SIDPERS, 
STARFIARS  and  STANF^S,  collectively  called  the  Army  Standard  Information  Management  System 
(ASIMS).  Dedicated  circuits  link  fifteen  TRADOC  installations  to  the  DMCs  to  use  ASIMS.  ASIMS 
networking  currently  uses  the  SNA  protocol,  employing  low  capacity  (9.6KB)  long  haul  circuits. 

ASIMS  circuits  are  also  used  to  interconnect  the  mainframe  platforms  that  support  TRADOC's 
Installation  Support  Modules  (ISMs)  and  PROFS/OVVM  e-mail  users. 

During  1997,  TRADOC  fielded  2,874  copies  of  a  COTS  software  package  across  the  command  to 
support  an  alternative  coimection  to  ASIMS,  via  the  NIPRNET,  that  will  allow  termination  of  the 
dedicated  circuits  after  1999.  These  TN3270E  software  packages  are  better  described  in  the  context  of 
the  mainframe  replacement  architecture  (see  paragraph  4.4.2.31. 

See  also: 

4.3. 2.3  Platforms— Installation  Level 

4.3.4.3  Installation  Management  Applications 

4.3. 1.4  Networks—Installation  Level 

Networks  that  span  a  TRADOC  installation  are  referred  to  as  a  CAN.  Operational  requirements  for 
action  officers  to  reach  worldwide  destinations  drive  TRADOC  installations  to  introduce  CANs  into 
their  data  transport  system.  There  can  be  no  "air  gaps"  between  the  data  source  and  receiver.  CANs 
provide  data  transport  among  an  installation's  LANs  and  link  all  connected  LAN  users  into  WANs. 
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There  is  no  precise  boundary  between  a  LAN  and  a  CAN,  but  the  CAN  is  generally  thought  of  as  the 
outside  cable  plant  that  spans  the  installation,  with  extensions  to  user  locations,  and  all  equipment 
required  to  interface  the  independently  operating  LANs  into  the  CAN.  CANs  also  include  network 
management  components,  and,  depending  on  their  architecture,  may  include  area  distribution  nodes 
(ADNs)  that  concentrate  data  and  provide  the  entry  point  into  the  CAN  for  end  user  systems  within  an 
area  of  the  installation.  The  outside  cable  plant  at  a  typical  TRADOC  installation  includes  a  fiber  optic 
ring  to  serve  as  a  data  distribution  backbone.  The  cable  plant  required  from  the  backbone,  or  ADNs,  to 
user  concentrations  is  then  installed  in  prioritized  stages. 

There  are  two  protocol  environments  in  TRADOC  for  networks  at  the  installation  level:  the  older 
SNA  network,  and  a  newer  set  of  networking  components  that  are,  or  are  capable  of  migrating  to,  an 
open  architecture  CAN. 

4.3.1.4.1  SNA  Network  Segments 

TRADOC  installations  still  maintain  SNA  CAN  segments  to  provide  access  to  their  IBM  4381 
platforms  (see  Figure  9).  These  segments  are  becoming  more  mission  specific  (e.g.,  TRADOC  ISM 
users)  as  common  user  applications  (e.g.,  PROFS/OVVM  e-mail)  are  migrated  to  open  architecture 
segments.  SNA  users  gain  access  to  the  host  via  an  IBM  3278  terminal  emulation  environment.  There 
are  declining  numbers  of  true  IBM  327x  terminals  still  in  use.  Most  users  instead  access  the  network 
from  a  PC  with  a  3278  emulation  card,  coimected  to  a  cluster  controller,  e.g.,  an  IBM  3174,  connected  in 
turn  to  a  front-end  communications  processor  (FEP),  e.g.,  an  IBM  3725.  Other  access  methods  include 
dial-up  VT-100  emulation  devices  with  protocol  converters,  SNA  networks  with  dumb  3278  terminal 
devices,  and  SNA  gateways  to  LANs. 


Defense  _ 
Megacenter 


Figure  9.  Notional  SNA  CAN  segment 

As  described  in  paragraph  4.3. 1.3.4.  users  may  also  coimect,  via  an  FEP  over  a  dedicated  circuit  for 
SNA  traffic,  to  a  DMC  to  use  ASIMS  applications.  Alternatives  based  on  using  the  NTPRNET  and  the 
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internet  protocol,  rather  than  continued  use  of  SNA,  are  also  in  the  process  of  being  fielded  (see  4.4.2.3h 

4.3.1.4.2  Open  Architecture  CANs 


TRADOC's  strategy  for  interconnecting  heterogeneous  IS  into  a  CAN  is  to  emphasize  a  common 
user  architecture,  vice  dedicated  circuits,  employing  open  interfaces  in  compliance  with  the  JTA-Armv. 

In  the  baseline,  most  installations  have  a  FDDI  ring  to  use,  or  build  upon,  as  the  backbone  of  a  CAN 
to  interconnect  user  locations,  carrying  TCP/IP  traffic  (Figure  101.  TRADOC  has  invested  in  common 
user  connectivity  fi'om  the  backbone  to  key  user  locations. 


In  some  locations,  TRADOC  has  moved  beyond  FDDI  to  ATM.  PM  CUITN  is  currently  upgrading 
the  entire  Fort  Bliss  CAN  using  ATM  technology.  HQ  TRADOC  is  funding  several  insertions  of  ATM 
segments  as  well  through  KEI.  Most  migration  to  ATM  has  occurred  through  installation  level  efforts. 
Fort  Gordon  provides  an  example.  Fort  Gordon  upgraded  their  backbone  infrastructure  to  a  155mbps 
ATM  cloud  consisting  of  5  ATM  work  group  switches  servicing  ATM  devices  with  1  OC-3c  port  and  12 
switched  Ethernet  ports.  The  ATM  infi'astructure  upgrade  is  compatible  with  existing  SBIS  Ethernet, 
Schedule  D  VTC  facilities.  Educational  Television  network,  and  Fort  Gordon’s  Professional 
Development  Network  (PDN). 


Organization  LANs 


Organization  LANs 


Figure  10.  Notional  FDDI  CAN  segment 


TRADOC  installations'  baseline  CANs  are  at  various  levels  of  capability.  The  "Fort  TRADOC" 
project  is  the  DCSIM's  effort  to  create  a  standard  baseline  level  of  information  transport  at  the 
installations.  Appendix  B  provides  a  graphic  overview  of  the  baseline  CAN  at  each  TRADOC 
installation.  Data  from  Appendix  B  is  also  maintained  on  the  DCSIM  homepage. 

See  also: 

4.4. 1.4  Networks— Installation  Level 
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5.1.3  Fort  TRADQC 


For  more  information: 

http://www-tradoc.armv.mil/netviz/index.html 

4.3.1.5  NetworkS“local  level 

A  network  at  the  local,  or  building,  level  is  generally  called  a  local  area  network  (LAN).  In  the 
baseline  system  architecture,  the  coverage  and  the  architecture  of  LANs  varies,  with  the  Ethernet 
topology  and  the  Novell  operating  system  predominating,  but  with  the  Microsoft  NT  operating  system 
showing  a  greater  growth  trend.  According  to  data  reported  in  the  1997  TPRISM  data  call,  TRADOC 
operates  236  Novell  LANs,  68  NT  LANs,  36  Banyan  VINES  LANs,  and  316  LANs  with  other,  or 
unreported,  network  operating  systems. 

4.3.2  Platforms 


Platforms  are  the  next  layer  up  from  networking  in  the  TRM.  The  platform 
layer  encompasses  computing  hardware,  operating  system  and  system  support 
service  software.  The  discussion  below  is  organized  by  integration  levels. 


4.3.2.1  Platforms—Enterprise  Level 


Mission 

Applications 


Support 

Applications 

Platforms 

External 

Environment 


Computing  is  distributed  in  TRADOC.  The  command  does  not  have  a  centralized  enterprise  level 
platform.  In  the  1980s,  TRADOC  completed  a  program  to  field  common  platforms,  an  IBM  4381,  to 
support  enterprise  processes,  but  these  platforms  were  distributed  to  each  installation  and  operated  at 
that  level.  That  program,  called  TRADOC  Information  Systems  Integration,  supported  the  command 
level  capability  called  TRADOC  Decision  Support  System,  primarily  by  running  the  PROFS/OVVM 
and  ISM  applications.  These  IBM  4381  computers  remain  in  the  baseline  system  architecture  and  are 
described  below  as  installation  level  platforms  in  paragraph  4.3. 2. 3. 

4.3.2.2  Platforms—Mission  Level 

While  there  are  standard  platform  configurations  associated  with  some  mission  level  processes, 
TRADOC  has  no  significant  mission  level  platforms  that  are  centrally  operated  by  a  functional 
proponent  for  the  whole  mission  area.  In  some  cases,  the  DMCs  fill  the  role  for  centralized  mission  level 
platforms.  DMCs  host  a  variety  of  standardized  mission  applications,  e.g.,  SIDPERS,  STARFIARS  and 
STANFINS,  sometimes  collectively  called  the  ASIMS. 

The  most  important  mission  level  platforms  operated  by  TRADOC  are  associated  with  installation 
management  processes.  The  Army  initiated  a  long  range  effort  called  the  Sustaining  Base  Information 
Services  (SBIS)  to  develop  a  full  range  of  applications  to  support  installation  management  processes  at 
both  the  installation  and  MACOM  level.  The  Army  also  initiated  an  interim  effort,  the  Installation 
Transition  Processing  (ITP)  Installation  Support  Modules  (ISM)  project,  to  enhance  installation 
management  Army-wide  imtil  SBIS  was  operational.  Both  the  SBIS  and  ITP  ISM  programs  field  and 
employ  mission  level  platforms. 

SBIS  platforms  are  scheduled  for  fielding  during  1997-98.  The  platforms  are  therefore  described  as 
part  of  the  objective  architecture  in  paragraph  4.4.2.2. 

As  a  phase  within  the  ITP  program,  the  DMCs  centrally  operate  ISMs  on  SUN  690  platforms.  PM 
SB  A  is  just  concluding  the  fielding  for  decentralized  ITP  platforms  at  TRADOC  installations.  These 
platforms  are  described  as  part  of  the  objective  architecture  in  paragraph  4.4.2.2.  As  the  migration  to 
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local  operations  is  completed,  and  until  all  ISM  applications  have  been  developed  and  fielded  for 
operation  on  ITP  platforms,  the  baseline  system  architecture  for  ISMs  continues  to  include  centralized 
platforms  at  two  DMCs  (Huntsville  and  St.  Louis),  accessed  by  personal  computers  located  at  the 
installations. 

There  are  scattered  other  mission  level  platforms  fielded  to  TRADOC  installations  to  host  mission 
applications,  e.g.,  the  Automated  Retail  Outlet  System  (AUTOROS)  and  Automated  Instruction 
Management  System  (AIMS).  The  AUTOROS  platform  is  a  Unisys  Micro.  AUTOROS  supports  the 
DOL  and  DIS  with  inventory  management,  parts  accountability,  receipts  and  issues  and  manpower 
utilization.  The  majority  of  the  AUTOROS  system,  excluding  inventory  management,  will  be  replaced 
by  SAMS/I-  TDA.  HQ  TRADOC  will  provide  a  replacement  Y2K  compliant  system  to  support  this 
function.  The  AIMS  platform  is  a  DEC  VAX  and  supports  DOTD's  with  academic  data  on  students, 
audit  trails  for  enrollments,  attrition,  graduation,  test  administration,  effectiveness  evaluation,  and 
scheduling. 

4.3.2.3  Platforms—Installation  Level 

The  primary  installation  level  computing  platform  in  the  baseline  system  architecture  is  an  IBM 
mainframe  in  the  43XX  (e.g.,  4381)  product  line,  with  the  VM/SP  operating  system,  version  5.0  or 
higher.  There  are  typically  IBM  3380  disk  drives  and  IBM  3422  tape  drives  associated  with  the 
mainframe.  TRADOC  provides  centralized  maintenance  contract  support  for  these  mainframes.  The 
most  important  applications  on  these  mainframes  are  the  PROFS/OVVM,  for  e-mail,  scheduling  and 
bulletin  board  support,  and  TRADOC's  ISMs.  DOIMs  also  developed  applications  unique  to  the 
missions  of  their  serviced  end  users,  some  of  which  continue  running  on  these  platforms. 

All  of  these  mainframes  will  be  phased  out  by  2000.  Hardware  fielding  actions  to  prepare  for  that 
phase,  although  complete  at  several  installations,  are  still  on-going.  The  replacement  hardware  is 
therefore  described  in  the  objective  architecture.  Nine  unique  applications,  a  mix  of  mission  and 
installation  level,  must  be  migrated  to  another  platform  or  application.  The  TRADOC  ISMs  are  being 
replaced  by  Army  standard  systems.  Associated  software  migration  is  discussed  in  the  objective 
architecture. 

See  also: 

4.4.2.3  Platforms—Installation  Level 

4.4.4.3  Installation  Management  Applications 
5.2.1  IBM  mainframe  replacement 

For  more  information: 

http://www-tradoc.annv.mil/dcsim/mlcr/mlcr.htm 

4.3.2.4  Platforms—Personal  Level 

Throughout  the  command,  there  are  about  35,000  personal  computers.  Most  are  based  on  Intel 
processors  ranging  from  286  to  Pentiums  and  run  MS-DOS  or  Windows  as  their  operating  system.  The 
large  majority  of  TRADOC  PCs  are  acquired  via  Army's  centralized  IDIQ  contracts,  which  has  helped 
standardize  on  the  Intel  based  machines.  HQ  TRADOC  does  not  track  more  precise  statistics  for  the 
distribution  of  PCs  at  TRADOC  installations. 

4.3.3  Support  applications 
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The  next  TRM  layer  is  software  applications,  which  includes  two  sub-layers: 
support  and  mission  applications.  Support  applications  cut  across  mission  areas, 
e.g.,  e-mail  and  word  processing,  while  mission  applications  are  designed  for 
specific  end  user  fimctions.  This  section  discusses  support  applications  in  the 
baseline  architecture. 


4.3.3.1  E-mail 


TRADOC  had  a  recent  ten  year  history  of  using  PROFS/OVVM  for  its  command-wide  e-mail 
system.  That  is  changing  across  the  command  as  fimctional  organizations  install  open  networks  and 
servers  that  can  run  open  e-mail  applications.  Only  about  a  third  of  TRADOC  e-mail  users  still  use 
PROFS/OWM,  which  is  hosted  on  the  IBM  4381  mainframes.  Figure  1 1  shows  the  distribution  of 
users  on  various  e-mail  packages. 


Mission 

Applications 

Support 

Applications 

Platforms  | 

External  I 
Environment 


Figure  11.  Distribution  of  e-mail  users 

4.3.3.2  Messaging 

TRADOC  reconfigured  its  messaging  architecture  during  1997  to  introduce  the  TRADOC  Message 
Service  Center  (TMSC)  concept.  The  new  architecture  provides  efficiencies  that  enable  DOIMs  to 
reprogram  TCC  persoimel  for  the  simultaneous  operation  of  current  e-mail  systems,  the  TCC,  and  DMS 
as  it  evolves. 

Figure  12  illustrates  the  typical  TCC  architecture  prior  to  implementation  of  TMSC  concept.  Each 
TCC  operated  an  independent  messaging  configuration  directly  connected  to  the  AUTODIN. 
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Figure  12.  Typical  TCC  configuration  in  1996 


The  TMSC  concept  makes  five  key  modifications,  described  below,  nearly  all  of  which  are  now 
completed  at  each  TRADOC  installation. 

=>  Relocation  of  ASSIST  Terminals  to  SSOs 

The  Automated  Special  Security  Information  Systems  Terminal  (ASSIST)  equipment,  used 
exclusively  to  process  Defense  Special  Security  Communications  System  (DSSCS)  traffic,  is  being 
relocated  to  the  installation  SSO.  This  action  reduces  the  workload  in  the  TCC,  permits  downgrading  the 
security  level  of  the  TCC  to  a  secret-high  and  improves  the  capabilities  and  efficiency  of  the  SSO. 

=>  Establishment  of  TRADOC  Message  Service  Centers 

TMSCs  (see  also  paragraph  4.3.1.2.2.31  are  located  at  Forts  Gordon,  Leavenworth  and  Monroe. 
Each  provides  centralized  message  distribution  services  to  several  subscriber  installations.  Figure  13 
depicts  a  TMSC  and  a  typical  subscriber.  Subscriber  installations  process  their  AUTODIN  traffic 
through  their  assigned  TMSC,  which  is  directly  connected  to  the  AUTODIN.  TMSCs  provide  dial-in 
service  to  subscribers  for  classified  and  outgoing  unclassified  messages.  Unclassified  incoming  message 
traffic  is  processed  by  the  AUTODIN  Mail  Server  (AMS)  at  the  TMSC  and  routed  to  the  subscriber's 
Army  Standard  Electronic  Mail  Host  (ASEMH).  The  ASEMH  is  a  transitional  DMS  server  used  for  the 
receipt  and  onward  delivery  of  unclassified  messages  using  X.25  protocols. 
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Figure  13.  Typical  TMSC  and  subscriber  TCC  configurations 


An  important  part  of  this  architecture  is  maintaining  high  quality  messaging  during  exercises, 
mobilization,  and  militaty  operations.  TMSCs  provide  "message  watch"  for  specific  t5rpes  of  messages 
to  enable  connected  stations  to  take  full  advantage  of  part-  time  operations.  Maximum  use  of  secure  and 
non-secure  facsimile,  administrative  telephones,  and  STU-III  communications  are  employed  to  permit 
reduced  operations  at  supported  stations.  TMSCs  will  directly  contact  subscribers'  on-call  TCC 
personnel  and/or  duty  officers  to  determine  appropriate  actions  on  incoming  messages.  TMSCs  operate 
on  a  part-time  schedule  in  a  reduced  threat  (peace  time)  environment.  Operations  during  network 
interruptions,  facility  impairments,  periods  of  increased  missions  and/or  political  tensions,  to  include 
mobilization,  may  require  extended  hours  of  TMSC  operation. 

=>  Replacement  of  AMSs  with  ASEMHs 

All  TRADOC  installation  TCCs  other  than  those  designated  as  TMSCs,  have  had  the  AMS  in  their 
TCC  replaced  with  an  ASEMH. 

=>  Consolidations  ofTCC/DPI 

Since  TRADOC  installations'  TCCs  are  now  using  portable  equipment,  they  have  the  opportunity 
for  a  simple  self-help  consolidation  of  the  TCC  with  the  DPI's  e-mail  processing  section.  This  action  has 
been  successfully  completed  at  TRADOC  installations  with  benefits  including  shared  operations  and 
maintenance  capabilities,  resource  savings  and  improved  efficiencies  in  systems  administration. 

=>  Conversions  to  Dial-Up  Service 

All  TRADOC  TCCs  supported  by  a  TMSC  have  disconnected  their  dedicated  AUTODIN  circuit 
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and  now  process  all  their  classified  and  outgoing  unclassified  AUTODIN  messages  as  a  dial-in 
subscriber  to  the  ports  on  their  assigned  TMSC's  classified  processing  terminal.  STU-III  devices  are 
employed  for  transmission  security.  This,  and  other  networWng  aspects  of  the  TMSC  architecture,  were 
discussed  together  with  AUTODIN. 

See  also: 

4.3.1. 2.2.3  Automatic  Digital  Network  (AUTODINl 

4.3.3.3  Office  Automation 

TRADOC  uses  a  variety  of  COTS  products  for  office  automation  applications,  e.g.,  word 
processing,  graphics  and  spreadsheets.  The  specific  applications  vary  by  vendor  throughout  the 
command  and  even  at  installation  level.  Thus,  it  is  not  uncommon  to  find  several  vendor  specific  support 
applications  and  resultant  file  formats  in  a  cross  section  of  TRADOC  organizations.  Most  TRADOC  PC 
users  already  have,  or  can  access,  capabilities  for  generating  and  reading  a  variety  of  common  office 
automation  file  types.  However,  in  the  acquisition  process  that  has  led  to  the  baseline  architecture,  there 
have  been  no  constraints  to  ensure  common  capabilities  are  acquired.  The  migration  strategy  for 
achieving  the  objective  architecture  includes  tighter  enforcement  of  product  selection  based  on 
capabilities  for  generating  and  reading  the  JTA-Armv  standard  file  formats,  listed  in  Table  16.  and 
publication  of  command- wide  preferred  products  lists  (see  Table  61. 

4.3.3.4  Videoteleconferencing 

TRADOC  has  eighteen  studio  grade  VTC  facilities,  which  can  connect  to  facilities  worldwide  via 
military  operated  networks  (see  paragraph  4.3.1.2.2.21.  TRADOC  has  also  installed  desktop  VTC 
equipment  that  supports  point  to  point  and  multipoint  VTCs  among  TRADOC  eommanders  and  HQ 
TRADOC  staff  principals.  The  DVTC  common  user  imit  is  the  PictureTel  Live  50,  which  began 
shipment  to  TRADOC  users  in  July  1997.  Until  recently,  the  primary  system  in  the  baseline  system 
architecture  was  AT&T's  VISTIUM.  The  minimum  PC  requirements  for  the  PictureTel  unit  are:  386  or 
faster  CPU,  8  megabyte  (MB)  random  access  memory  (RAM),  ISA  or  EISA  Bus,  VESA  Advanced 
Feature  Connector,  20MB  Disk  Space,  and  SVGA  or  VGA  Monitor.  The  ciurent  version  of  PictureTel 
requires  Windows  3.1  or  Windows  95  operating  system.  However,  PictureTel  has  issued  a  product 
announcement  for  a  Windows  NT  version  to  be  available  in  the  fall  1997.  The  PictureTel  unit  will 
interface  to  other  vendors'  systems  that  conform  to  the  International  Telecommunications  Union  (ITU) 
H.320  standard  for  video  data.  It  supports  data  sharing  and  collaboration  on  files  from  other  applications, 
e.g.,  word  processing  documents.  To  support  multipoint  VTCs,  TRADOC  also  installed  at  Fort  Monroe 
AT&T's  Multipoint  Control  Unit.  This  imit  will  connect  multi- vendor  products  via  the  H.320  standard. 
Each  caller  dials  into  the  control  unit  and  the  multipoint  connections  are  established.  Figure  14  shows 
the  distribution  of  DVTC  in  the  baseline  system  architecture. 
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Figure  14.  DVTC  Distribution 


4.3.4  Mission  applications 

TRADOC  uses  mission  applications  that  are  developed  and  supported  by  a 
variety  of  sources.  TRADOC's  ATSC  has  developed  many  of  our  training 
applications.  TRADOC  still  relies  on  a  set  of  installation  management 
applications  that  were  developed  by  TRADOC  programmers  at  the  Ft.  Sill 
DOIM.  Ft.  Monroe  DOIM  also  supports  some  MACOM  level  and  Cadet 
Command  applications.  Most  mission  applications,  e.g.,  battle  simulations  and 
ST  AMIS,  are  developed  and  sustained  outside  of  TRv^OC  or  are  tailored 
adaptations  of  commercial  products.  The  discussion  below  briefly  describes  how 
some  major  types  of  applications  are  used  in  TRADOC. 
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Appendix  C  provides  a  list,  with  brief  descriptions,  of  most  mission  applications  used  in  TRADOC. 

4.3.4. 1  Training  Applications 

Although  the  categories  are  not  entirely  mutually  exclusive,  training  applications  can  be  grouped  as 
follows: 

•  Management  information  systems  (MIS)  to  support  high  transaction  processes,  e.g.,  managing 
correspondence  courses,  scheduling  classrooms  and  equipment,  and  maintaining  student  records. 
Example  MIS  applications  include:  AIMS,  TREDS-R,  RECBASS  and  TMWS.  AIMS-R  is  the 
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cornerstone  for  modernizing  training  MIS  and  will  absorb  the  functions  of  many  MIS  in  the 
baseline  architecture. 

•  Database  management  systems  to  catalog  and  track  various  training  entities,  e.g.,  devices,  course 
materials,  course  descriptions,  requirements  and  resources.  Example  database  applications  include 
AIDE,  ATRRS,  STAARS,  and  TEXMIS. 

•  Training  development  tools  that  support  the  preparation  of  training  materials,  e.g.  ASAT  and 
COTS  products  for  multimedia  courseware  development. 

•  Training  tools  that  assist  in  the  conduct  of  training,  e.g.,  simulations  and  simulators  (see  paragraph 
4.3 .4.2).  and  computer  based  instruction.  Training  tools  are  at  a  very  immature  state  compared  to 
the  vision  for  Classroom  XXL 

Refer  to  Army  Training  Information  Management  Program  (ATIMP)  documentation  for  detailed 
information  on  training  MIS  and  databases. 

See  also: 

Appendix  C.  8.1  Training  Applications 

For  more  information: 
http://www.atimp.armv.mil/ 

4.3.4.2  Models  and  Simulations  (M&S) 

M&S  applications  are  used  in  three  of  TRADOC's  four  key  processes:  combat  development, 
doctrine  and  training.  The  Army  categorizes  M&S  into  three  domains.  The  Advanced  Concepts  And 
Requirements  (ACR)  domain  deals  with  strategy  (developing  concepts,  milit^  options,  and  force 
requirements  in  theater  and  regional  contexts);  force  development  (assessing  improvements  in 
operational  and  tactical  capabilities)  and  requirements  generation  and  materiel  development  (assessing 
system  performance,  developing  cost  analyses,  determining  logistics  for  sustained  operations).  The 
Training,  Exercises  And  Military  Operations  (TEMO)  domain  supports  individual  and  collective 
training,  exercises  and  mission  rehearsal.  The  Research,  Development  and  Acquisition  (RDA)  domain 
covers  analytical  capabilities  for:  science  &  technology  thrusts,  weapon  systems  developments  and  test 
&  evaluation.  Mapping  these  domains  into  TRADOC's  processes,  combat  developers  and  doctrine 
developers  are  the  largest  users  of  ACR  M&S  and  trainers  use  TEMO  M&S,  but  individual  applications 
may  be  used  by  more  than  one  set  of  functional  end-users.  Users  outside  TRADOC  are  the  primary  users 
of  RDA  M&S,  e.g..  Army  Materiel  Command,  acquisition  Program  Managers,  Operational  Testing  and 
Evaluation  Command,  and  Space  and  Strategic  Defense  Command. 

M&S  are  generally  divided  into  three  types: 

•  Constructive:  mathematically  oriented  tools  for  analysis,  e.g.,  war  games.  They  are  usually 
identified  with  the  large  scaled,  complex  computer-driven  models  most  often  associated  with 
exercises  dealing  with  battalions,  brigades,  divisions,  corps,  and  EAC.  Constructive  simulations 
are  in  wide-spread  use  in  the  Army  and  in  TRADOC. 

•  Virtual:  manned  simulators  interacting  within  a  synthetic  environment.  Virtual  simulations  are 
often  associated  with  crew-served  weapons  systems  and  focus  on  skill  development  and  practice. 
These  simulations  closely  replicate  all  or  parts  of  tanks,  armored  personnel  carriers,  aircraft,  and 
other  equipment  and  normally  require  the  trainee(s)  to  immerse  into  the  simulation.  Virtual 
simulations  are  often  referred  to  as  simulators.  Examples  are  found  in  flight  simulators  at  Fort 
Rucker,  tank  simulators  at  Fort  Knox,  infantry  fighting  vehicle  simulators  at  Fort  Benning,  and 
engineer  vehicle  simulators  at  Fort  Leonard  Wood. 

•  Live:  soldiers  and  equipment  operating  together  against  an  actual  force  for  purpose  of  training  or 
experimentation.  Live  simulations  primarily  use  simulators  to  replicate  weapons  effects.  Live 
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simulations  can  take  place  almost  anywhere  the  maneuver  space  is  available,  but  the  primary 
training  facilities  in  the  Army  that  use  live  simulations  are  at  the  National  Training  Center  (NTC), 
the  Joint  Readiness  Training  Center  (JRTC),  and  the  Combat  Maneuver  Training  Center  (CMTC). 
At  these  facilities,  much  of  the  battlefield  is  instrumented,  primarily  by  Multiple  Integrated  Laser 
Engagement  System  2000  (MILES  2000)  and  Core  Instrumentation  Systems. 

4.3.4.2.1  Distributed  Interactive  Simulation 

The  Army's  core  Distributed  Interactive  Simulation  (DIS)  Facilities  (CDF)  are  located  on 
TRADOC  installations  at  Forts  Knox,  Benning  and  Rucker.  Other  nodes  with  long  haul  connectivity 
include  Forts  Bliss,  Huachuca,  Sill,  Leavenworth,  Leonard  Wood,  and  Gordon.  DIS  is  a  communication 
protocol  that  supports  Advanced  Distributed  Simulation  technology  in  which  operators  interact  through 
interconnected  simulators  and  simulations  (constructive,  live  and  virtual)  tied  together  through  a 
standard  commvmication  design.  DIS  technology  enables  combat,  doctrine  and  training  developers  to 
simulate  innovations  required  for  designing  Force  XXL  It  supports  mission  area  analyses,  concept 
formulation,  requirements  definition,  and  prototyping.  Each  core  site  is  equipped  with  crewed 
simulators,  semi-automated  forces  (SAF)  simulators  to  provide  computer  generated  forces,  display 
systems  to  provide  experimenters  a  view  of  the  virtual  battlefield  and  data  collection  and  analysis  tools. 
Crewed  simulators  are  available  for  tanks,  helicopters,  air  defense  systems,  communication  systems  and 
a  generic  command  and  control  console.  STRICOM  manages  the  CDFs. 

4.3.4.2.2  Family  of  Simulations 

The  Family  of  Simulations  (FAMSIM)  is  the  collective  name  for  many  of  the  M&S  applications 
used  in  TRADOC's  baseline  architecture.  FAMSIM  simulates  operations  at  the  tactical,  operational,  and 
theater  levels.  It  is  a  set  of  constructive  models:  Corps  Battle  Simulation  (CBS),  Brigade/Battalion  Battle 
Simulation  (BBS),  Janus,  Tactical  Simulation  (TACSIM),  Combat  Service  Support  Training  Simulation 
System  (CSSTSS),  and  Spectrum. 

BBS  is  used  for  command  post  exercise  (CPX)  training  for  BDE/BN  commanders/staffs.  It  is  used 
at  Corps,  in  conjunction  with  CBS,  Division  in  conjunction  with  CBS,  Reserve  battle  projection  centers, 
as  well  as  TRADOC  schools.  BBS  is  a  fixlly  distributed  system  of  five  MicroVax  3100-40s  utilizing  a 
LAN  to  drive  a  standard  configuration  of  10  workstations  (DEC  VT  320  terminals).  It  uses  the  Virtual 
Memory  System  (VMS)  5.5  operating  system.  In  TRADOC,  BBS  suites  are  currently  employed  at  Fort 
Leavenworth,  Chemical  School,  Infan^  School,  Engineer  School,  Artillery  School,  Air  Defense 
Artillery  School,  Armor  School,  Aviation  School,  Academy  of  Health  Sciences  and  the  Sergeants 
Majors  Academy  at  Fort  Bliss,  TX. 

CBS  is  used  for  training  corps  commanders  and  battle  staff,  major  subordinate  commands,  and 
major  subordinate  elements  of  headquarters  of  the  corps.  It  exercises  command  and  staff  skills  in  control 
of  joint  operations,  tactical  forces,  combined  arms  forces,  maneuver  forces,  and  the  combat  support  and 
combat  service  support  systems  in  an  operational/tactical  environment.  CBS  Version  1.5.3  runs  on  a 
network  of  DEC  Virtual  Address  Extension  (VAX)  7620  with  the  VMS  operating  system.  In  TRADOC, 
the  only  CBS  suite  is  installed  at  National  Simulation  Center  (NSC). 

Janus  is  targeted  to  company/team  level  training.  Janus  runs  under  the  UNIX  operating  system  on 
Hewlett  Packard  715/50  microcomputers.  TRADOC  schools  have  two  each  eight  workstation  suites. 

The  TACSIM  is  the  Army's  leading  intelligence  collection  and  dissemination  model.  TACSIM  aids 
in  the  training  of  intelligence  staff  skills  fi'om  the  design  of  collection  requirements  to  the  analysis  of 
raw  intelligence.  It  supports  intelligence  training  from  MI  Battalion  through  Echelons  Above  Corps.  The 
TACSIM  equipment  suite  includes;  DEC  ALPHA  1000,  VAX  3196,  VAX  3140,  three  SUN  SPARC  II 
Ces  and  SUN  SPARC  20.  It  is  used  at  NSC  and  USAICS. 

CSSTSS  is  a  combat  service  support  (CSS)  CPX  driver  which  can  be  used  as  a  stand-alone 
simulation  or  to  stimulate  exercise  play  for  the  collective  training  of  CSS  commanders  and  staffs  in 
Echelons  Above  Corps,  Corps,  Corps  Support  Commands,  Divisions,  and  Division  Support  Commands 
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as  well  as  their  subordinate  headquarters  down  to  the  battalion  level.  CSSTSS  1.5  is  an  IBM-based 
system.  It  is  run  on  an  AMDAHL  5890  computer  mainframe  that  is  fielded  at  the  Fort  Leavenworth  and 
Fort  Lee.  Exercises  are  supported  by  remote  coimection  to  either  host. 

Spectrum  is  used  to  train  operations  other  than  war.  It  runs  in  a  Windows  environment  on  IBM 
Pentium  133  MHz  processor. 

4.3.4.2.3  Analytical  M&S 

TRADOC  uses  a  group  of  applications  for  analysis,  e.g.,  to  produce  Cost  and  Operational 
Effectiveness  Analyses.  The  primary  user  is  TRADOC  Analysis  Center  (TRAC)  at  Ft.  Leavenworth. 
Operators  typically  use  SUN,  Hewlett  Packard  or  Silicon  Graphic  workstations  connected  to  VAX  or 
Cray  platforms  ruiming  the  model.  Specific  applications  represent  various  echelons  with  different 
degrees  of  resolution  as  depicted  in  Figure  15. 


Simulation  Echelon  Resolution 


Figure  15.  Analytical  M&S 


TACWAR  models  theater  joint  and  combined  operations,  including  groimd  combat,  air  combat, 
logistics,  command  and  control  and  chemical  warfare.  Users  include  TRAC,  the  Army  War  College  and 
various  warfighting  commands. 

Eagle  models  corps  and  division  in  joint  and  combined  scenarios.  It  includes  command  and  control, 
maneuver,  direct  and  indirect  fires,  helicopter  warfare,  air  defense  and  intelligence  fusion. 

Vector-in-Commander  (VIC)  models  corps  operations  with  a  theater  slice,  in  a  joint  context. 
Operations  include  maneuver,  fire  support,  command  and  control,  engineering,  air  defense,  combat 
service  support  and  chemical  warfare.  Users  include  TRAC,  Engineer  School,  Artillery  School  and 
Intelligence  School. 

The  Combined  Arms  and  Support  Task  Force  Evaluation  Model  (CASTFOREM)  is  a  high 
resolution  model  used  for  representing  direct  and  indirect  fires,  maneuver,  fixed  wing  aircraft  and 
helicopters,  information  operations  and  limited  combat  service  support.  Although  its  resolution  is  down 
to  item  level,  CASTFOREM  is  not  yet  DIS  compliant. 

4.3.4.3  Installation  Management  Applications 

Installation  management  is  the  TRADOC  mission  area  with  the  longest  automation  history.  As  a 
result,  the  baseline  architecture  is  a  variety  of  applications  from  several  programmatic  sources  used  in  a 
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diverse  set  of  functional  areas. 

PEO  STAMIS  is  charged  with  fielding  STAMIS  and  other  standard  applications  for  use  Army¬ 
wide.  Some  STAMIS  have  been  adopted  as  DOD  migration  systems,  either  in  current  or  improved  form. 
Some  STAMIS  that  TRADOC  uses  are  hosted  on  centralized  processors  operated  at  the  DMCs  (see 
Table  4)  and  are  collectively  known  as  ASIMS.  TRADOC  installations  access  ASIMS  through  the 
communications  processor  associated  with  the  installation  level  IBM  4381  mainframe  or  the 
replacement  equipment  currently  being  fielded  by  TRADOC.  Other  STAMIS  are  written  for  local 
operation,  or  can  be  operated  in  two  architectures.  Appendix  C  gives  a  brief  description  of  various 
STAMIS  applications. 


Table  4.  STAMIS  Use 
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Several  PEO  STAMIS  applications,  collectively  called  ITP  ISMs,  are  currently  hosted  on  platforms 
at  the  DMCs  but  are  scheduled  to  migrate  to  a  distributed  architecture  fielded  to  installations.  Most  have 
already  been  fielded  to  TRADOC  installations.  Another  PEO  STAMIS  set  of  applications,  the  SBIS 
modules,  are  designed  to  be  run  at  installations.  Most  are  also  scheduled  for  fielding  during  1997 
coincident  with  the  fielding  of  platform  suites.  Appendix  C  gives  a  list  and  brief  description  of 
applications  in  both  programs. 

At  the  other  end  of  the  integration  spectrum,  TRADOC  still  employs  installation  unique 
applications,  developed  by  TRADOC  DOIMs  for  local  operation.  These  applications  support  mission 
requirements  unique  to  specific  installations  and  typically  run  on  the  installation  level  IBM  mainframes. 
There  are  about  70  such  installation  unique  applications.  As  part  of  its  Project  Change  of  the  Century, 
TRADOC  is  evaluating  all  of  these  applications.  Many  will  be  retired. 

To  standardize  the  most  common  installation  management  applications  used  in  TRADOC,  Fort  Sill 
and  Fort  Monroe  DOIMs  developed  about  25  TRADOC  installation  support  modules  (ISM)  in  the 
I980's.  See  paragraph  ^  in  Appendix  C  for  a  list  of  TRADOC  ISMs.  These  were  the  primary 
applications  run  on  the  installation  level  IBM  mainframes  discussed  in  paragraph  4.3.2. 3.  Use  of  the 
TRADOC  ISMs  is  declining  as  replacement  applications  become  available.  All  TRADOC  ISMs  will  be 
retired  as  the  replacement  applications  are  fielded  prior  to  2000  (see  Table  71.  Most  TRADOC  ISMs 
interface  with  STAMIS  systems,  running  at  DMCs,  to  retrieve  current  information  for  the  local 
TRADOC  ISM  database  tables  and  return  transactions  and  updated  information  to  the  STAMIS.  These 
information  exchange  requirements  are  a  large  part  of  the  traffic  carried  on  the  dedicated  circuits 
described  in  paragraph  4.3. 1.3.4. 

See  also: 

5.2.2  SBIS 

5.2.3  ITP 

5.4.5. 1  Installation  Support  Modules 


26 


Appendix  C:  Mission  Applications 
For  more  information: 

http://www-tradoc.annv.mil/dcsim/v2k/restrict/v2k-ais/v2k-ais.html 

4.4  Objective  system  architecture 

In  TPRISM,  the  "objective"  system  architecture  is  the  vision  of  the  future  that  is  driving  our  current 
planning  and  programming.  It  is  not  determined  by  an  arbitrary  time  boundary,  e.g.,  10  years  out.  If  the 
migration  strategy  includes  a  near  term  target  architecture  as  a  transition  to  reach  the  objective  end  state, 
that  is  described  in  this  section  as  well.  To  make  the  migration  strategy  more  evident,  the  discussion  of 
the  objective  architecture  below  is  organized  into  the  same  categories  as  were  used  throughout  section 
^  for  the  baseline  system  architecture.  Refer  to  Chapter  5  for  management  information  on  projects 
mentioned  below  as  the  means  for  achieving  parts  of  the  objective  system  architecture. 

The  most  fundamental  changes  to  TRADOC's  baseline  system  architecture  are  those  required  to 
migrate  toward  a  standards  based  architecture  that  maximizes  common-user  assets  and  extends 
client-server  capabilities  to  the  action  officer  level.  This  means  steady  improvement  and  maintenance  of 
installation  CANs  and  LANs,  and  personal  level  computers.  A  solid  infrastructure  of  these  components 
will  position  TRADOC  for  fUture  growth,  interoperability  and  exploitation  of  DoD,  Army  and 
commercial  investments  in  new  products.  Generic  system  components  that  are  important  pieces  of  this 
objective  architecture  include: 

Wide  Area  Network  (WAN)  -  interconnect  geographically-dispersed  CANs  and  servers.  WANs  can  range 
from  a  complex  structure  of  packet  switches  to  simple  point-to-point  lines. 

Internet  -  a  worldwide  public  network  of  interconnected  servers.  The  servers  provide  various  services  to 
heterogeneous  client  platforms.  Notable  services  include  file  transfers  and  information  searching  using 
hyperlinks  (world  wide  web). 

Intranet  -  a  network  limited  to  servers  inside  security  devices  designed  to  control  access  to  a  specific  set 
of  users.  Servers  on  an  intranets  can  offer  the  same  type  of  user  services  as  on  the  Internet.  Network 
segments  may  be  shared  with  public  networks  since  the  security  devices  protect  access  to  data  and 
services  on  the  servers. 

Campus  Area  Network  (CAN)  -  interconnects  LANs  using  a  broadband  network  (often  referred  to  as  an 
installation  backbone)  covering  a  geographic  area  larger  than  that  of  the  individual  LANs,  but  usually 
restricted  to  a  geographic  region  about  the  size  of  a  campus  or  military  installation.  The  CAN  includes 
cabling  (usually  single-mode  fiber)  and  network  devices  (routers,  gateways,  and  bridges)  which  enable 
information  transport  in  accordance  with  protocols  (e.g.,  FDDI  or  ATM/Synchronous  Optical  Net 
(SONET)).  If  the  function  of  a  component  is  to  provide  an  inter-network  interface  into  the  common  user 
installation  level  network,  then  TPRISM  categorizes  the  component  as  part  of  the  CAN. 

Area  Distribution  Node  (ADN)  -  concentrates  the  data  from  end  user  systems  and  lower  level  networks 
and  provides  their  entry  point  into  a  higher  level  network,  i.e.,  CAN. 

Switch  -  provides  a  bridge,  or  connection,  among  multiple  networks. 

Router  -  interconnects  two  or  more  networks  and  passes  data  packets  between  them.  A  router  performs 
two  distinct  functions:  route  processing  and  packet  switching.  Route  processing  determines  the  next  hop, 
i.e.,  where  to  forward  a  packet  that  is  received.  Routers  exchange  connectivity  information  with  other 
routers  to  determine  network  addresses  and  adapt  to  changes.  Packet  switching  is  the  actual  forwarding 
of  a  received  packet  on  the  basis  of  the  source  and  destination  addresses  of  the  packet,  and  the  next  hop 
routing  information  in  the  router.  A  nimiber  of  other  packet-level  functions  (such  as  filtering)  may  also 
be  performed  during  the  forwarding  operation. 

Hub  -  Hubs  are  networking  devices  to  connect  a  group  of  circuits  at  one  point  on  a  network,  and 
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typically  include  a  chassis,  power  supplies,  management  and  host  modules.  Hubs  are  often  repeaters, 
bridges  or  routers.  Hubs  enable  single  point  management  functions,  e.g.  changing  connections.  Hubs  can 
come  bundled  with  various  degrees  of  capabilities,  e.g.,  an  intelligent  hub  will  communicate  network 
management  information  to  a  network  administrator's  workstation.  Hubs  can  be  employed  at  all  levels  of 
networking,  i.e.,  WAN,  CAN,  LAN. 

Local  Area  Network  (LAN)  -  interconnects  clients  and  servers  within  a  small  geographical  area,  usually 
within  a  building.  There  is  no  universally  accepted  boundary  between  a  LAN  segment  and  a  CAN,  but 
TPRISM  generally  uses  the  term  LAN  for  the  network  segment  among  collocated  end-users,  while  CAN 
is  the  term  used  for  the  installation's  data  backbone  network  that  inter-connects  the  users'  LANs. 

Server  -  a  host  or  computer  that  processes  information  and  shares  information  with  other  servers  through 
communications  media.  A  server  generally  executes  aspects  of  application  programs  used  by  a  group  of 
users,  although  there  are  a  variety  of  other  server  capabilities,  e.g.,  data  storage.  A  server  can  also  act  as 
a  router. 

Client  -  a  computer,  often  a  PC  at  the  action  officer  level,  that  makes  requests  for  services  (e.g.,  for  a 
database  record)  to  a  server.  The  server,  often  a  higher  performance  computer,  fills  those  requests  and 
sends  the  result  via  a  network.  Since  the  client  and  server  must  cooperate,  both  follow  standardized 
protocols. 

4.4.1  External  environment 

The  TRM  includes  networking  and  external  data  sources  in  the  external 
environment  layer. 


4.4.1.1  External  data  sources 

External  data  sources  will  be  important  components  of  the  objective  system 
architecture.  Software  architectures  will  increase  reliance  on  external  data  sources 
fi'om  which  client  applications  can  pull  data.  External,  distributed  databases  will 
also  be  used  extensively  for  electronic  coordination  and  information 
dissemination  and  reuse.  Centralized  search  engines  and  gateways,  e.g., 
TRADOC's  CALL  Gateway  and  commercial  services  like  Web  Crawler  and 
Yahoo!,  will  help  direct  users  to  specific  information  sources. 

4.4.1. 1.1  CALL  Database 

The  CALL  Database  operations  are  centrally  executed  at  Ft.  Leavenworth.  The  objective  of  the 
CALL  Database  is  to  enhance  the  Army's  corporate  memory  by  digitizing  records  from  both  actual  and 
synthetic  operations.  Actual  operations  include  material  from  Desert  Storm,  Rwanda,  Haiti,  and 
Hurricane  Andrew.  Synthetic  operations  are  mainly  those  conducted  at  Combat  Training  Centers.  The 
primary  collection  and  analysis  tool  is  the  CALL  Collection  and  Observation  Management  System 
(CALLCOMS).  It  assists  Combined  Arms  Assessment  Teams  (CAAT)  in  formulating  collection  plans, 
categorizing  observations  and  identifying  trends.  It  can  run  on  a  stand-alone  PC  for  individual  observers 
or  from  a  local  area  network  to  better  support  the  massive  amount  of  data  collected  by  a  CAAT.  All  data 
produced  through  CALLCOMS  is  fed  directly  into  the  CALL  database.  Although  products  will  continue 
to  be  produced  in  paper  format  for  some  time  to  come,  electronic  access  and  dissemination  is  the 
objective  architecture.  CALL  will  support  four  different  electronic  access  capabilities:  e-mail.  World 
Wide  Web,  an  on-line  document  management  and  retrieval  system,  and  the  master  database. 

Every  publication  that  is  produced  in  paper  form  is  also  being  produced  in  multiple  electronic 
forms,  including  hypertext.  CALL  is  using  the  WWW  for  its  primary  distribution  means.  Many 
supporting  documents  are  also  available  in  the  Automated  Historical  Archives  System  (AHAS),  a 
document  management  and  retrieval  system.  AHAS  contains  the  most  recent  collection  of  contingency 
operation  documents.  It  is  operated  by  the  Combined  Arms  Center  Historian  and  has  a  collection  of  over 
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500,000  pages  of  documents  dealing  with  topics  such  as  disaster  and  humanitarian  assistance  and  the 
Gulf  War.  For  qualified  users,  CALL  will  provide  direct  access  to  the  master  CALL  database.  Access 
will  be  through  a  windowed  graphical  user  interface,  allowing  the  researcher  to  sort,  filter,  and  retrieve 
the  same  data,  in  its  original  format,  that  CALL  uses  to  publish  its  finished  products.  The  objective 
architecture  capability  is  information  on  demand  from  any  authorized  user  from  any  PC.  All  forms  of 
written,  video  and  audio  products  supported  by  multiple  data  bases  will  be  available  to  worldwide 
tactical  operations  centers  (TOCs),  staff  sections,  schools  and  individuals.  The  CALL  Database  will 
access  a  large  volume  of  information,  but  will  assist  the  user  in  tailoring  the  search  and  the  retrieved 
results  to  specific  information  requirements. 

For  more  information: 
http  ://call.armv.mil/call.html 

4.4.1.1.2  Army  Training  Digital  Library  (ATDL) 

The  ATDL  will  provide  worldwide  access  to  a  distributed  digital  repository  of  training  and  doctrine 
knowledge.  It  will  provide  WWW-type  search  and  retrieval  services.  The  ATDL,  centrally  operated  at 
Ft.  Eustis,  will  provide  transparent  access  to  the  distributed  training  products  and  courseware  of  all 
TRADOC  schools  and  therefore  is  an  important  enabler  of  distance  learning.  As  part  of  the  WARNET 
initiative  of  Army  Training  XXI,  ATDL  is  linked  to  implementation  of  the  Army  Distance  Learmng 
Plan's  (ADLP)  development  of  infrastructure  and  delivery  technologies  for  the  Total  Army  School 
System  (TASS). 

The  ATDL  will  contain  approved  Field  Manuals  (FM),  Training  Circulars  (TC),  Drills  and  Officer 
Foundation  Standards  (OFS)  and  Army  Correspondence  Course  Program  (ACCP)  materials.  ATDL  will 
also  store  training  scenarios  for  reuse  in  developing  Mission  Training  Plans  (MTP)  and  Training  Support 
Packages  (TSP)  for  unit  and  institutional  training.  MTP,  OFS  and  Soldier  Training  Publications  (STP) 
will  be  available  only  as  "virtual"  HTML  documents  through  ATDL.  The  ATDL  will  eliminate  the 
resource  intensive  process  of  distributing  doctrinal  and  training  information  in  printed  form.  The  ACCP 
will  ultimately  offer  over  2600  subcourses  to  enrolled  students  through  the  ATDL. 

The  ATDL  will  provide  an  intelligent  gateway  to  other  training  related  systems.  For  example, 

ATDL  users  will  be  able  to  view  data  on-line  from  the  Training  Module  (TRAMOD)  Executive 
Management  Information  System  (TEXMIS).  The  user  will  submit  a  request  for  data  to  ATDL,  which 
will  connect  to  TEXMIS,  locate  and  extract  the  data,  add  the  HTML  tags,  and  display  the  data. 

Retrieved  data  can  also  be  imported  to  other  training  applications,  e.g.,  SATS  and  ASAT. 

For  more  information: 

http  ://www.  atsc-armv.org/  atdls  .html 

4.4. 1.1. 3  Internet/intranet  access 

Servers  connected  to  either  the  Internet  (within  DOD,  the  DISN)  or  to  a  TRADOC  intranet  will 
continue  to  be  important  data  sources.  Open  protocols,  e.g.,  TCP/IP,  FTP  and  HTTP,  to  manage 
transactions  will  enable  increased  use  of  shared  data  among  heterogeneous  systems.  PC's  and  networks 
available  at  the  action  officer  level  will  support  Intemet/intranet  access.  Military  activities,  including  HQ 
TRADOC,  will  continue  to  push  information  required  for  effective  mission  accomplishment  through 
websites.  Intranet  access  is  distinguished  from  the  baseline's  Internet  access  by  its  limitation  to  servers 
inside  a  network  firewall,  as  designed  by  the  using  organization.  Intranets  can  be  integrated  at  any  level 
(command,  installation,  etc.),  but  the  key  is  that  access  is  purposely  controlled  to  a  specific  set  of  users 
who  are  authorized  to  use  the  data  found  on  the  servers.  Intranets  will  allow  TRADOC  to  electronically 
share  data  that  cannot  be  posted  on  a  publicly  accessible  internet  site,  e.g.,  draft  doctrine,  system 
priorities,  and  meeting  schedules.  The  same  kind  of  information  retrieval  services,  using  the  same 
protocols,  that  are  available  on  the  Internet  can  be  made  available  on  intranets,  so  that  users  can  locate 
and  pull  authorized  information  using  the  same  skills.  End  users  will  use  the  same  platform  and  software 
for  accessing  both  the  internet  and  TRADOC  intranets.  Implementation  of  intranets  will  require  network 
security  devices  beyond  those  available  in  the  baseline  system  architecture. 
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4.4.1.2  Networks—Enterprise  Level 

The  enterprise  level  includes  networks  for  telephone,  or  voice,  and  data  transport.  However,  the 
distinction  will  become  increasingly  meaningless  in  the  objective  system  architecture.  Networks  will 
evolve  toward  a  broadband  integrated  services  digital  network  (BISDN)  capable  of  providing  the 
bandwidth  for  high  speed  data  applications  and  voice,  plus  the  video  transport  included  in  TRADOC's 
information  exchange  requirements.  ATM,  a  fast  packet,  or  cell,  switching  technique,  is  the  objective 
solution  for  implementing  BISDN  at  the  enterprise  level.  BISDN,  using  the  ATM  protocol,  permits  the 
transmission  of  voice,  data,  video,  and  imagery  services  over  a  single  network  and  allows  the  use  of  a 
single  switch  configuration  for  all  network  services.  SONET  will  be  the  predominant  transmission 
standard  for  WANs.  The  ATM  cells  are  statistically  multiplexed,  without  pre-assigned  time  slots,  and 
synchronously  inserted  into  a  SONET  frame.  This  enables  dynamic  allocation  of  capacity.  SONET 
provides  a  complete  set  of  standard  optical  interfaces  without  redundant  electronics.  Competition  among 
vendors  who  offer  standardized  equipment  will  reduce  future  costs.  Industry  is  already  attempting  to 
realize  these  advantages  by  developing  SONET-based  products  and  services  as  the  standards  become 
available.  For  example,  AT&T,  MCI,  and  US  Sprint  have  announced  SONET-based  network  support 
and  have  begun  conversion  to  SONET  standards. 

4.4.1.2.1  Telephone  Network 

The  Army's  MACOM  Telephone  Modernization  Program  (MTMP)  provides  TRADOC 
installations  with  telephone  switch  upgrades.  The  architecture  will  be  a  distributed  configuration,  with  a 
dial  central  office  (DCO)  and  ADNs  to  support  user  concentrations  and  remote  locations.  All  MTMP 
switching  upgrades  will  use  ISDN  equipment  capable  of  end-to-end  digital  N-ISDN.  MTMP  provides 
interfaces  with  existing  telephone  outside  cable  plant  at  ADNs  and  interfaces  with  WAN  ISDN.  The 
standard  user  telephone  interface  will  continue  to  be  two- wire  analog  at  an  RJ-1 1  connector  for  voice 
commimications.  Users  who  need  a  digital  connection  should  be  provided  a  two-wire  narrowband-ISDN 
(N-ISDN)  2B+D  U  interface  at  an  RJ-1 1  connector  or  an  N-ISDN  2B-I-D  S  or  T  interface  with  two 
four-pair  cables  at  RJ-45  connectors. 

4.4.1.2.2  Data  Network 

TRADOC's  enterprise  level  network  for  data  transport  will  be  a  WAN,  or  combination  of  WANs, 
engineered  and  managed  at  a  higher  level  of  integration  than  TRADOC  itself  A  study  being  conducted 
by  the  TRADOC  Analysis  Center  (TRAC),  in  coordination  with  the  DCSIM,  will  help  establish 
requirements,  costs  and  alternatives  for  TRADOC's  WAN  usage  during  FY99  through  2005.  The  study 
results  are  scheduled  to  be  reported  out  in  January  1998.  The  scope  of  the  study  originated  with  M&S 
communication  requirements,  but  its  scope  was  expanded  and  the  study  results  are  expected  to  influence 
TRADOC's  broader  WAN  modernization  strategy. 

TRADOC  will  continue  to  use  the  DoD's  DISN  as  its  common-user  WAN.  DISN  is  a  set  of  digital 
communications  networks  maintained  by  DISA,  providing  high  speed,  high  bandwidth  transport  for  data 
and  video.  The  objective  architecture  continues  the  same  three  major  router  network  components  as  the 
baseline  (see  Figure  161: 

•  NIPRNET  for  unclassified  information  transport 

•  SIPRNET  for  secret 

•  JWICS  for  top  secret  and  sensitive  compartmented  information. 

Every  TRADOC  installation  will  have  access  to  the  NIPRNET.  NIPRNET  will  carry  the  bulk  of 
TRADOC's  traffic  above  the  installation  level.  The  Army's  Circuit  Bundling  Initiative  (CBI),  formerly 
called  the  Army  Regional  Transition  Network  (ARTNET),  may  provide  WAN  service  in  a  target 
architecture  leading  to  NIPRNET  improvements.  At  least  nine  TRADOC  installations  will  access  the 
SIPRNET  to  support  their  Threat  Management  Office:  Bliss,  Knox,  Rucker,  Sill,  Huachuca,  Lee, 
Gordon,  Benning,  and  Leonard  Wood.  TRADOC  activities  at  Redstone  and  Aberdeen  Proving  Grounds 
will  also  access  SIPRNET.  JWICS  nodes  will  be  at  Forts  Huachuca,  Monroe  and  Leavenworth.  Each  of 
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these  will  serve  as  an  access  point  for  2-3  other  TRADOC  sites.  Monroe  serves  Knox,  Rucker  and 
Benning.  Leavenworth  serves  Leonard  Wood  and  Sill.  Huachuca  serves  Bliss  and  White  Sands  Missile 
Range.  Since  terminating  equipment  must  be  in  a  Sensitive  Compartmental  Information  Facilities 
(SCIF),  sites  without  a  SCIF  are  not  currently  planned  for  JWICS  access:  Carlisle,  POM,  Jackson,  Eustis 
and  Lee. 

All  three  network  components  share  a  common  backbone.  The  data  flow  is  kept  separate  by  the 
router  logic.  The  routing  tables  in  each  network  list  only  other  routers  in  the  same  network.  NIPRNET 
has  two  Internet  gateways,  known  as  Fix-West  and  New  York  network  access  point  (NAP).  TRADOC 
users  will  access  Internet  hosts  and  services  through  these  NIPRNET  gateways. 


Routing  Tables 
List  Only 

SIPRNET  Routers 


Routing  Tables 
List  Only 
JWICS  Routers 


Figure  16.  DISN  components 


The  DISN  evolutionary  strategy  will  be  executed  in  stages.  The  near  term  (through  2000) 
architecture  is  essentially  a  modernized  baseline  DISN.  It  replaces  the  DCTN  services  and  consolidates 
about  200  individual  networks  within  DOD.  The  cut-over  of  current  circuits  from  the  expiring  contract 
into  the  new  DISN  infrastructure  is  scheduled  to  be  completed  in  eight  regionally  defined  phases.  This 
transition  involves  cut-overs  at  over  500  sites  across  the  CONUS.  Figure  18  shows  the  eight  regions 
being  used  to  schedule  the  transition. 

The  mid  term  (2001-2005)  architecture  services  and  capabilities  will  include: 

•  Intelligent  directory  service 

•  NISDN/BISDN  services  (fixed  environment). 
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•  Initial  ATM  network  (deployed  environment). 

•  Multilevel  security. 

•  NISDN  secure  terminal  equipment. 

•  Distributed  interactive  simulation. 

•  Multipeer/multicast  service  for  data  conferencing. 

•  Automated  provisioning  and  bandwidth  management. 

The  far  term  architecture  (2006-2010)  will  achieve  BISDN  services  in  the  fixed  network  segment 
and  an  ATM  capability  for  the  deployed  network  segment. 

The  DISN  CONUS  infrastructure  includes  circuit  switches  (SWs),  bandwidth  managers  (BWMs), 
and  DISN  CONUS  Regional  Control  Centers  (RCCs).  On  the  installations,  the  infi-astructure  is 
connected  to  private  branch  exchanges  (PBXs),  4-wire  subscribers,  dedicated  services,  VTC  hubs, 
network  management  systems,  and  access  and  backbone  transmission  services.  A  SONET  backbone  will 
connect  the  BWMs  to  each  other  and  to  installations.  Figure  17  depicts  these  components  in  a  logical 
graphic  while  Figure  18  shows  physical  locations. 


Figure  17.  DISN  CONUS  architecture 
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H  Bendvudth  Manager  Only 

'A  DSS  Swilch  and  Bandvudth  Manager  Collocated 

■jit  DSS  Switch  and  BandvMdth  Manager  Remoted 


Figure  18.  DISN  regions  and  switch  locations 

•  Switches.  Each  of  the  DISN  CONUS  Switched  Service  (DSS)  switches  are  connected  to  two  or 
more  other  switches  hy  a  SONET  transmission  backbone  through  the  BWMs.  Each  switch  is 
designated  as  the  access  area  switch  for  a  group  of  using  sites. 

•  Bandwidth  Managers.  The  BWM  is  a  digital  cross-connect  system  that  manages  the  access  and 
backbone  links.  The  initial  BWM  installation  will  support  Optical  Carrier  Level  3  Signal  (OC-3) 
circuits  from  the  access  and  backbone  contractor  (AT&T  Federal  Services)  and  Digital  Signal 
(Level  1)  (DSl)  circuits  for  the  test  network.  The  test  network  is  used  to  insert  new  technology 
into  DISN  operations.  The  BWM  sites  have  three  different  configurations:  23  sites  have  a  B\^^ 
only,  9  sites  have  a  BWM  with  a  switch  collocated,  and  3  sites  have  a  BWM  with  a  switch 
remotely  located. 

•  Videoteleconferencing  Services.  Initially,  video  services  will  provide  H.320  standards  based, 
unclassified  and  secure,  multi-point  services  for  dedicated  and  dial-up  connections  via  three 
CONUS  video  switching  hubs.  The  VTC  network  transition  has  three  target  stages: 

=>  VTC  Hubs.  Installation  and  testing  of  the  three  VTC  hubs  and  their  inter-nodal 
backbone. 

=>  Circuit  Transition.  Installation  and  testing  of  local  access  circuits  to  sites  for 
dedicated  or  dial-up  connections. 

=>  Videoteleconferencing  Facilities  (VTF)  Transition.  Upgrading  the  VTF 
coder/decoder  (CODEC)  to  incorporate  H.320  standard  conference  controlling,  testing  the 
access  to  the  new  DISN  circuit,  and  installation  and  testing  of  the  DVS-G  reservation  and 
scheduling  system. 

TRADOC  installations  will  own  and  manage  customer  premises  equipment  (CPE)  necessary  to 
interface  their  installation  level  servers  with  WANs.  TRADOC  CPE  and  servers  must  support  the 
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TCP/IP  protocol  interface.  The  network  access  can  take  several  forms,  including  ATM,  FDDI,  a  serial 
direct  connection  (X.25)  or  Ethernet  (IEEE  802.3).  CPE  will  link  to  a  router  provided  by  the  ADRP, 
manufactured  by  Cisco  Communications.  The  Army's  strategy  for  installations'  system  architecture  is  to 
connect  all  Army  servers  to  Army  CPE  rather  than  to  connect  directly  to  a  DISA  router.  ADRP  routers 
will  provide  each  installation  a  single,  common  user  access  point  for  multiple  hosts  and  LANs.  This 
intemetted  architecture  allows  the  Army  to  pay  for  only  one  long  haul  connection  rather  than 
individually  for  each  host  or  LAN  with  DISN  connectivity.  Installation  DOIMs  will  be  responsible  for 
installation  level  management  of  ADRP  routers.  Their  configuration  will  vary  according  to  the 
installation,  but  as  a  minimum,  each  will  provide  IEEE  802.3  and  serial  link  switches. 

See  also: 

5.1.1  DISN 


For  more  information: 
http://www.disa.mil/DISN/disnhome.html 

4.4.1. 3  Networks—Mission  Level 

Increasingly,  unique  mission  level  networks  will  become  logical  sets  of  connectivity,  physically 
carried  over  the  integrated  DISN.  Unique  circuits,  e.g.,  ASIMS  and  TNET,  coming  into  the  installation 
to  support  stovepipe  applications  will  be  reduced  (Figure  191.  The  scheduled  transition  from  DSI  to 
DISN  Enhanced  IP  Services  provides  an  example. 

During  CY97,  the  DSI  will  transition  to  the  DISN  and  DOD  will  stop  its  centralized  funding  of  the 
networking.  Current  planning  indicates  about  40  subscribers  will  remain  after  the  transition.  All  fourteen 
of  TRADOC's  subscribing  organizations  have  committed  to  transition.  The  DSI  services  (networking, 
VTC,  help  desk  support,  scheduling)  will  be  provided  as  DISN  Enhanced  IP  Services.  Sites  will  be 
interconnected  through  the  NIPRNET  45mbps  ATM  backbone.  The  existing  Bay  Networks  T/20  tail  site 
routers  will  be  replaced  with  Cisco  7204/4500  routers,  using  the  Resource  Reservation  Protocol  (RSVP). 
RS  VP  provides  bandwidth  reservation  between  the  sender  and  receivers  through  RS  VP-capable  routers. 
RSVP  allows  end-users  to  request  membership  in  a  multicast  group  at  any  time.  Multicast  groups  are 
dynamically  established  via  a  multicast  routing  protocol,  such  as  the  Distance  Vector  Multicast  Routing 
Protocol  (DVMRP)  or  Protocol  Independent  Multicasting  (PIM).  The  Motorola  Improved  Network 
Encryption  System  (INES)  will  be  upgraded  from  release  1C  to  ID.  The  INES  supports  classified 
communications.  Existing  VTCs  will  be  replaced  with  H.320  compliant  desktop  VTCs,  which  are  can  be 
upgraded  to  H.323  compliance. 
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Baseline/Target  WAN  Architecture 


Figure  19.  Objective  WAN  Architecture 
4.4.1.4  Networks—Installation  Level 

The  WANs  will  bring  data  to  TRADOC  installations,  but  once  at  the  gate,  data  will  still  need  a 
means  of  transport  throughout  the  installation.  The  network  component  for  this  is  the  CAN.  TRADOC's 
CANS  will  be  consistent  with  the  JTA.-Armv  and  compatible  with  DISA  and  Army  managed  network 
programs.  Given  our  resource  constraints,  TRADOC's  strategy  for  installing  installations'  CANs  is  to 
bring  all  installations  up  to  the  baseline  architecture  centered  on  a  FDDI  backbone,  and  then  migrate 
over  time  to  an  objective  system  architecture  using  ATM  technology.  Figure  20  provides  an  overview  of 
the  migration  path.  To  implement  the  target  phase,  TRADOC  is  seeking  funding  for  a  command-wide 
packajge  of  requirements  titled  "Fort  TRADOC"  through  the  KEI  process  (see  paragraph  5.1.31  and  the 
insertion  of  a  more  robust  "Fort  TRADOC"  package  into  the  Army's  installation  sequence  list  (ISL)  for 
PPC4rs  fielding  schedule  (see  paragraph  5.1.21.  The  objective  architecture  depends  on  the  full  fielding 
of  PPC4I  throughout  TRADOC. 
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Figure  20.  Migration  Path  for  CANs 


FDDI  CANs  are  defined  by  open  standards  and  will  remain  the  basis  for  many  segments  of 
TRADOC's  CANs  for  several  iterations  of  installations'  target  architectures.  Gradually,  through  Fort 
TRADOC,  CUITN  and  functional  proponents’  and  installations'  efforts,  ATM  segments  will  be 
introduced,  beginning  with  high  priority,  high  bandwidth  users.  ATM  segments  will  migrate  TRADOC 
installations  closer  to  the  objective  architecture,  which  is  based  on  the  PPC4I  program's  design  decisions 
and  TRADOC's  own  operational  requirements  for  moving  large  amounts  of  information  down  to  the 
action  officer  and  student  levels.  The  Army's  largest  provider  of  networking  components  to  installations 
is  the  Common  User  Installation  Transport  Network  (CUITN)  program,  part  of  the  PPC4I.  Its 
architecture  must  influence  TRADOC's  objective  system  architecture,  so  that  TRADOC's  own 
investments  will  increase  our  readiness  to  accept  and  integrate  networking  components  provided  by  this 
program. 

When  the  PM  for  CUITN  fields  a  CAN  to  an  installation,  all  components  required  to  bring  the 
installation  up  to  CUITN's  design  standards  are  inserted.  The  PM  uses  components  that  comply  with 
JTA-  Army  standards  to  create  a  CAN  based  on  ATM  switching.  CUITN  fields  dual  ATM  switches  as 
the  heart  of  the  CAN  in  CUITN  DCOs  (C-DCO).  One  C-DCO  is  collocated  with  the  existing  DCO 
facility  and  another  is  generally  placed  in  a  facility  that  already  houses  other  IS,  e.g.,  a  DPI  or  an  RSU. 
In  this  way,  the  C-DCO  collocates  several  components  for  centralized  access  and  management,  e.g.,  a 
telephone  switch,  router,  DISN  gateway  and  installation  level  e-mail  host(s).  The  C-DCO  are 
interconnected  to  distributed  ADNs  via  single  mode  fiber  optic  (SFMO),  supporting  SONET/ATM 
transmission  at  optical  canier-3  (OC-3)  capacitiy  (155Mbs),  scaleable  to  OC-48  (2.5Gbs).  ADNs 
concentrate  data  fi’om  building  level  systems  and  provide  the  entiy  point  to  the  backbone  CAN.  Small 
installations  require  one,  two,  or  three  ADN  locations  for  the  entire  installation.  A  medium  installation 
has  fom  to  fifteen  ADN  locations  and  a  large  installation  has  16  or  more.  Figure  21  provides  an 
abbreviated  view  of  the  major  components,  or  levels,  in  the  CUITN  architecture. 
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C  DCO  (A) 


Figure  21.  Generalized  CUITN  ATM  CAN  design 


The  DCOs  and  ADNs  are  connected  in  a  hierarchical  meshed  star  topology  (see  Figure  22.1  The 
hierarclucal  aspects  are  connections  from  DCO  to  ADN,  ADN  to  primary  and  secondary  hubs  in  end 
user  buildings  (EUB),  and  hubs  to  servers  and  user  workstations.  The  mesh  aspect  is  ADN  to  ADN 
cross-connections  for  survivability  and  load  leveling,  as  well  as  primary  building  hubs  to  alternate  ADN, 
if  required,  for  survivability.  DCO,  ADN,  and  hubs  are  equipped  with  an  Intelligent  Operation, 
Administration,  and  Maintenance  (lOA&M)  capability.  LAN  Emulation  (LANE)  makes  the  protocol 
conversions  that  permit  existing  applications  to  run  over  the  ATM  CAN. 
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Figure  22.  CUITN's  hierarchical  meshed  star  topology 


The  ADNs  in  turn  interface  with  scaleable  media  that  extend  service  to  end  user  buildings  through  a 
hub  (see  Figure  23).  Inside  the  building,  service  is  extended  to  user  locations  by  switched 
lOMbs/lOOMbs  Ethernet  or  is  continued  as  ATM  service,  depending  on  the  bandwidth  requirement  and 
available  ports  on  the  hub. 
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Figure  23.  CUITN  building  hubs 


For  more  information: 

http://138.27.209.61/integ/tmpl/appenx-a.htm 

4.4.1.5  NetworkS“Local  Level 

LANs  will  remain  a  fundamental  building  block  for  creating  command-wide  networking 
capabilities.  The  discussion  of  WANs  and  CANs  above  showed  LANs  as  the  "on  and  off  ramps", 
providing  the  ultimate  connection  with  the  user.  As  building  blocks,  it  is  essential  that  LANs  fit  into  a 
larger  system  architecture,  which  itself  is  constrained  by  the  technical  architecture.  TRADOC's  objective 
system  architecture  will  contain  a  heterogeneous  mix  of  vendors'  LAN  products,  but  they  will  all 
connect  to  the  higher  level  networks  via  interfaces  defined  by  open  standards.  The  technical  architecture, 
paragraph  6.1.1.  provides  the  required  standards  and  protocols,  but  to  reiterate  the  most  relevant, 
TRADOC  will  install  LANs  that  conform  to  IEEE  802.3,  and  support  TCP/IP  interfacing,  implement  the 
SNMP  set  of  management  protocols,  and  have  a  network  operating  system  (NOS)  that  can  run 
applications  using  Win32  or  POSIX  compliant  application  program  interfaces  (APIs). 

Aside  from  these  standard  capabilities  required  for  command-wide  interoperability,  the  system 
architecture  for  LANs  is  decided  at  installation  level,  or  lower.  ISEC  has  issued  useful  guidance  for  local 
consideration 'm  Design  Guidance  for  Local  Area  Networks,  Version  1.0,  31  October  1996.  For  example, 
to  facilitate  LAN  user  moves,  additions,  changes,  and  future  equipment  upgrades,  the  LAN  should  be 
laid  out  in  a  star  topology  with  an  intelligent  hub  at  the  center. 

Select  the  cable  type  that  suits  the  distances  and  bandwidth  requirements.  Useful,  but  not  exclusive, 
options  include  multi-mode  optical  fiber  and  twisted  pair.  Multimode  fiber  is  good  for  distances  up  to 
1.25  miles.  It  can  be  used  for  data,  voice,  and  video  traffic.  There  are  two  types  of  twisted  pair  cable: 
unshielded  twisted  pair  (UTP)  and  shielded  twisted  pair  (STP).  The  cost  of  UTP  will  usually  be  less  than 
any  other  cabling.  UTP  cable  is  familiar  to  installers,  small  in  diameter,  lightweight,  and  simple  to 
connect  and  terminate.  The  Electronics  Industries  Association  (EIA)/Teleconimunications  Industry 
Association  (TIA)  category  5  UTP  cable  will  cost  a  little  more  than  Category  3  UTP  cable,  but  the  extra 
cost  will  be  worth  it  over  time.  Category  5  UTP  cable  can  transmit  data  at  100  Mbps  to  support 
emerging  technologies  like  Fast  Ethernet  and  ATM.  Category  3  UTP  cable  is  limited  to  transmission 
speeds  of  16  MHz,  does  not  scale  upward,  and  is  rapidly  felling  into  disuse.  STP  cable  is  good  for 
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applications  that  require  high-speed  data  rates,  but  STP  cable  is  considerably  more  expensive  than  UTP. 
Based  on  the  above  considerations,  TRADOC  DCSIM  recommends  using  category  5  UTP  to  install 
most  LANs  in  TRADOC  facilities. 

TRADOC  expects  most  LANs  in  the  objective  architecture  will  include  a  cable  plant,  although 
wireless  LANs  may  find  a  niche  where  PC  mobility  is  a  major  requirement  or  in  specific  applications 
where  network  cables  are  impossible  or  difficult  to  install.  Wireless  LANs  may  also  be  used  to  augment 
or  back  up  wired  LANs  for  lower  bandwidth  applications. 

For  more  information: 
httD://138.27.209.61/integ/ 


Platforms  are  the  next  layer  of  the  TRM  after  networking.  The  platform  layer 
encompasses  computing  hardware,  operating  system  and  system  support  service 
software. 


4.4.2.1  Platforms—Enterprise  Level 


TRADOC  does  not  have  enterprise  level  platforms  in  the  baseline  and  has  no 
plan  to  create  any  in  the  objective  system  architecture.  TRADOC's  preferred 
approach  is  to  leave  information  processing  and  data  on  platforms  under  the 
control  of  the  installation  commanders.  TRADOC  will  continue  to  use  the 
centralized  platforms  run  by  DISA  Megacenters  for  standardized  DoD  and  Army 
applications.  These  platforms  are,  strictly  speaking,  outside  this  enterprise,  i.e., 
TRADOC. 

4.4.2.2  Platforms— Mission  Level 

With  the  trends  toward  more  distributed,  client-server  software  applications,  increased  processing 
power  of  smaller  platforms,  and  increased  connectivity  via  LANs,  functional  proponents  are  more  likely 
to  field  standard  platforms  to  perform  specific  mission  related  tasks. 

For  example,  trainers  are  considering  the  standard  platform  configurations  for  conducting  training  in 
a  Classroom  XXI  facility,  to  include  servers  for  the  classroom  and  the  Digital  Training  Access  Center. 
Other  training  platforms  will  be  distributed  at  the  personal  level,  but  will  have  configurations 
standardized  at  the  mission  level,  e.g.,  the  instructor  preparation  workstation,  instructor 
control/multimedia  workstation  and  the  student's  multimedia  workstation.  In  general,  the  configurations 
center  around  a  platform  with  a  Pentium  166  or  133  MHz  processor,  depending  on  the  workstation's  role 
as  server  or  client.  See  the  Army  Distance  Learnins  Program  Master  Plan  for  the  details  on  this  set  of 
mission  level  platform  architecture  recommendations. 

Combat  developers  and  trainers  will  field  platforms,  e.g.,  Silicon  Graphics  computers,  with  special 
features,  e.g.,  image  generators,  for  modeling  and  simulation.  Doctrine  writers  will  use  multi-media 
platforms  for  authoring  and  coordinating  compormd  documents.  While  these  examples  may  sound 
reminiscent  of  the  "stovepipe"  approach,  it  is  important  to  note  that  interoperability  with  other  platforms 
and  with  the  infrastructure  will  be  maintained  by  adhering  to  an  open  architecture  approach.  Platforms 
sized  and  acquired  to  satisfy  a  specific  mission  requirement  across  the  command  will  be  integrated  into 
the  larger  networking  and  processing  environment  by  openly  defined  interfaces. 

Platforms  for  the  installation  management  mission  area  deserve  a  fuller  description.  The  PEO 
STAMIS  selected  servers  from  the  International  Business  Machines  Corporation  (IBM)  reduced 
instruction  set  computer  (RISC)  6000  series  to  run  ITP  and  SBIS  applications.  SBIS  is  using  the  IBM 
RISC  6000  59H/R24  server  suite.  ITP  is  using  the  IBM  RISC  6000  39H  server,  which  is  compatible 
with  the  SBIS  platform.  The  39H  platform  has  128MB  of  system  memory  and  9  gigab3d;e  (GB)  of  disk 
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storage,  while  the  59H  and  R24  have  256MB  of  system  memory  and  6GB  and  13.5GB  of  disk  storage 
respectively.  Each  of  the  selected  suites  includes  a  5  GB  internal  8  millimeter  (mm)  tape  drive;  a  1  44 
megabyte  (MB)  3.5-inch  disk  drive;  a  2X  compact  disk  -  read-only  memory  (CD-ROM)  drive’  and 
commumcations  adapters  for  ATM,  FDDI,  or  Ethernet  lOBase-T  media.  Since  the  PM  sizes  the 
platforms  to  run  the  applications  fielded  with  the  platforms,  they  are  not  used  for  other  mission 
applications.  The  installations  shown  in  Fi^e  24  will  receive  SBIS  platforms.  This  fielding  plan 
ensures  standard  applications  can  be  run  at  installations  that  are  power  projection  platforms  (PPP)  and 
pov^r  support  platforms  (PSP).  In  TRADOC,  Ft.  Leavenworth  will  also  receive  an  SBIS  platform 
configi^ation.  By  the  end  of  FY97,  ITP  platforms  will  be  operational  at  33  CONUS  Army  installations 
to  run  the  ITP/ISM  applications. 


The  IBM  AIX  version  3.2.5  is  the  installed  operating  system.  It  is  POSIX-compliant,  i.e.,  with  IEEE 
Standard  1003.1-1990  (POSIX.l).  It  is  based  on  the  AT&T  UNIX  operating  system  V  (including  release 
2  and  release  3  extensions)  with  exceptions  as  required  for  POSIX  compliance. 


Plus  Ft.  Leavenworth 
Figure  24.  SBIS  Sites 


For  more  information: 

^://www-dcst.monroe.armv.mil/crxxi/toc.htm  (regarding  Classroom  XXI  platforms) 
http://138.27.209.61/integ/tmpl/appenx-c.htm  (regarding  installation  management  platforms) 

4.4.2.3  Platforms-Installation  Level 

•  will  migrate  away  from  this  architectural  niche,  and  specifically  away  from  the  IBM 

mainframe  platform  that  has  been  the  centerpiece  of  baseline  data  processing  installations  (DPIs).  These 
machines  are  inconsistent  with  goals  for  interoperability,  and,  if  nothing  else,  use  an  operating  system 
with  no  fix  for  the  year  2000  problem.  HQ  TRADOC  will  discontinue  the  contracted  maintenance  of 
these  mainframes  after  1999.  In  the  objective  system  architecture,  installations  will  use  a  combination  of 
platiorms  at  the  mission  and  local  levels  to  perform  the  functions  that  installation  level  mainframes  have 
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done  in  the  past.  The  degree  of  centralization  in  locating  and  operating  replacement  servers  is  an 
architectural  decision  made  at  each  installation.  A  high  degree  of  centralization,  e.g.,  server  farms 
would  approximate  an  installation  level  platform.  ’ 

making  several  architectural  changes  to  continue  support  for  interfacing  with  the 
DMC  ASIMS  applications  and  for  remote  job  entry  (RJE)  processing,  which  are  currently  sunnorted  bv 
the  installation  level  ffiM  mainframes.  t'y  j 

TRADOC  is  taking  two  steps  to  support  continued  interfacing  with  DMCs.  HQ  TRADOC  is 
fielding  at  installation  level  a  communications  front  end  processor  (FEP)  (Figm^JS)  ie  a  router  for 

NIPRNET  between  TRADOC  users  and  DMC  platforms  &at  run  the 

absorb  the  load  associated  with  connecting  ASIMS  users  to  the 
NIPRNET.  Additionally,  dunng  1997,  TRADOC  fielded  2,874  copies  of  TN3270E  software  across  the 
command  to  support  connectivity  down  to  end  users'  LANs.  Since  DMCs  are  equipped  with  IP  routers 
connected  to  the  NIPRNET,  the  TN3270  software  permits  end  users  to  emulate  IBM3270  terminals  and 
to  conduct  TELNET  sessions  with  ASIMS  applications  over  the  NIPRNET  using  the  IP  protocol.  The 
TN3270E  variant  purchased  by  TRADOC  also  supports  printing  on  local  devices  as  an  alternative  to 
using  the  RJE  services  generally  centralized  in  the  DPI. 

TRADOC  is  also  fielding  a  PC  based  RJE  configuration  (Figure  26V  It  consists  of  two  PCs  with 
specialized  hardware  and  software  to  continue  producing  micro  fiche  and  tape  backups,  and  using  high 
speed  printers,  while  running  ASIMS  applications  hosted  at  a  DMC.  Fielding  for  the  RJE  equipment  was 
completed  4Q97. 
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EXISTING  NETWORK  THAT 
WILL  STAY  UNTIL  Y2K 


■—  EXISTING  NETWORK  THAT 
WILL  NOT  STAY 

_ _  NEW  NETWORK  EQUIPMENT 

CC  =  duster  controller 


Figure  25.  Mainframe  replacement  FEP  configuration 
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Megacenter 


- NEW  EQUIPMENT  OR  CONNECTIONS 

-  OLD  EQUIPMENT  TO  REMAIN 

EQUIPMENT  OR  CONNECTION  NO  LONGER  REQUIRED  FORRJE 

Figure  26.  Mainframe  replacement  RJE  configuration 


See  also: 

4.3. 1.3.4  Army  Standard  Information  Management  System 
5.2.1  IBM  mainframe  replacement 

Appendix  C:  Mission  Applications- ASIMS 

4.4.2.4  Platforms—Local  Level 

Platforms  at  this  level  will  become  increasingly  important  IS  components  for  providing  processing 
power  to  action  officers.  Local  servers  will  be  networked  with  users  via  LANs  and  will  support  many 
common  user  support  applications,  e.g.,  e-mail,  office  automation  and  network  access.  The  degree  of 
centralization  used  in  locating  and  operating  such  platforms  is  an  architectural  decision  made  at  each 
installation.  The  selection  of  system  configurations  is  left  at  the  local  level,  within  the  constraints  of  the 
JTA-Aimv. 

4.4.2.5  Platforms—Personal  Level 

In  the  objective  system  architecture,  every  action  officer  in  TRADOC  will  have  processing  power 
available,  where  and  when  they  need  it.  In  a  client-server  architecture,  the  primary  client  device  will  be  a 
PC,  which  can  take  the  form  of  desktops,  notebooks,  hand-helds  or  personal  assistants.  Since  the 
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objective  system  architecture  is  one  PC  per  action  officer,  PCs  must  be  sufficiently  robust  to  run  a 
variety  of  applications  for  common  capabilities  (e.g.,  word  processors,  databases,  spreadsheets,  graphics) 
as  well  as  supporting  client  functions  for  mission  specific  applications.  PCs  will  also  be  the  users'  tool 
for  accessing  network  services,  e.g.,  e-mail,  file  transfer,  and  the  Internet. 

The  ability  to  run  DMS  and  multi-media  software  may  prove  to  be  the  drivers  in  specifying  PC 
characteristics.  Department  of  Defense  Personal  Computer  Policy  Implementation  Plan  FY 1995  -  FY 
2000.  March  31, 1995  established  performance  standards  for  PCs,  largely  based  on  running  DMS.  Using 
the  DoD  configuration,  TRADOC  coordinated  and  issued  recommendations  in  a  memo,  SUBJECT: 
TRADOC  FY98  Desktop  Computer  Preferred  and  Supported  Product  List,  15  Aug  97,  as  shown  in 
Table  5.  TRADOC  DOIMs  can  support  this  configuration  and  it  can  be  acquired  using  standard  DoD 
requirement  contracts.  The  same  memo  promulgated  Microsoft  Windows  NT  Workstation  as  the 
preferred  client  hardware  operating  system. 

For  more  information: 
http://www.dtic.mil/c3i/pcppmo2.html 

4.4.3  Support  Applications 

Table  4.  STAMIS  Use 

The  most  important  support  applications  for  TRADOC  will  continue  to  be 
e-mail,  now  including  messaging,  and  office  automation  tools. 
Videoteleconferencing  can  also  be  considered  a  support  application,  since, 
although  not  solely  a  software  application,  it  is  a  capability  that  rides  on  the 
networking  and  platform  infrastructure  and  crosses  mission  areas.  Lastly,  as  more 
documents  are  digitized,  printing  will  take  new  approaches. 


4.4.3.1  E-mail 
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In  the  objective  system  architecture,  TRADOC  will  use  DMS  compliant  products  to  provide  e-mail, 
or  individual  messaging.  DMS  will  also  be  the  organizational  messaging  system,  i.e.,  the  replacement 
for  AUTODIN,  DoD-wide.  TRADOC  will  migrate  toward  its  DMS  compliant  objective  architecture 
using  the  following  target  architectural  phases: 

Table  5.  Recommended  PC  configuration 
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DoD 

MINIMUM  CONFIGURATION 

TRADOC 

PREFERRED  AND  SUPPORTED 
HARDWARE  CONFIGURATION  FY98 

SPECint95  >=  3.2,  SPECfp95  >=  2.5  or 

CPU  mark  32  >=  220,  or  Icomp  >=  800 

- - - - - - i 

At  least  166  MHz  Pentium-class 

At  least  24M  RAM 

At  least  32  MB  RAM  expandable  to  128 

MB 

At  least  1  GB  hard  drive 

At  least  1 .6  GB  Hard  Drive 

LAN  interface 

Ethernet  LAN  interface 

10/100  BASE  5,2  &T 

2-PCMCIA  type  II  slots 

1  PCMCIA  adapter  supporting  2  type  II  and 

1  type  III 

Video  controller  -  minimum  256  colors, 
1024x768  pixels;  3MB  memory, 
drivers  for  operating  system 

Video  controller  -  minimum  256  colors, 
1024x768  pixels;  2MB  memory, 
upgradable;  drivers  for  operating  system 

At  least  4X  CD-ROM  Reader 

At  least  8X  CD-ROM  Reader 

3.5"  Floppy  Drive  capable  of  reading  and 
writing  both  1.44MB  and  720KB  diskettes 

3.5"  Floppy  Drive  capable  of  reading  and 
writing  both  1.44MB  and  720KB  diskettes 

1 -parallel  and  2-serial  ports 

1 -parallel  and  2-serial  ports 

Pointing  device  with  a  minimum  of  two 
buttons 

Pointing  device 

17"  color  monitor 

17"  color  monitor,  SVGA 

16-bit  sound  card  (for  multimedia 
applications)  and  drivers  for  operating 
system 

16-bit  soimd  card  (for  multimedia 
applications)  and  drivers  for  operating 
system 

expansion  slots: 

3  PCI 

expansion  slots: 

3  PCI  (2  shared) 

•  Phase  one  (present  through  31  Dec  1999)  installs/upgrades  the  installation  infrastructure  to  the 
level  needed  to  support  organizational  DMS. 

•  Phase  two  (present  through  30  Sep  2004)  consists  of  two  elements. 

=>  Upgrading/expanding  the  installation  infrastructure  and  PCs  to  the  level  needed  to 
support  individual  messaging. 

=>  Fielding  non-DMS  versions  of  the  PC  software  available  on  the  DMS  contract. 
Fielding  will  support  the  migration  to  an  installation  standard  e-mail/message  product 
while  using  lower-cost  commercial  versions  of  the  DMS  software,  e.g.,  Microsoft 
Exchange. 

•  Phase  three  (1  Oct  2004  through  30  Sep  2007)  provides  FORTEZZA  cards  and  DMS-compliant 
versions  of  the  user  agent  software  to  individual  messagers.  Use  of  DMS-compliant  products  by 
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all  individual  messagers  is  needed  to  realize  command-wide  operational  benefits  of  application 
interoperability. 

Within  the  DMS  program,  DoD  has  determined  that  open  standards  are  sufficiently  mature  to 
tolerate  a  wide  mix  of  vendors'  products  and  still  achieve  an  acceptable  level  of  interoperability  for 
e-mail.  However,  extended  capabilities  of  the  vendors'  packages  lack  a  solid  basis  in  open  standards  to 
ensure  their  interoperability  in  a  heterogeneous  environment.  To  ensure  all  capabilities  are  integrated  at 
the  command  level,  both  at  program  initiation  and  during  successive  target  architectures,  selection  of  a 
preferred  product  is  the  surest  course.  As  mentioned  above,  TRADOC  DCSIM  will  work  with  the 
installations  to  determine  the  product(s)  that  can  best  ensure  required  interoperability.  Per  TRADOC 
memo,  SUBJECT:  TRADOC  FY98  Desktop  Computer  Preferred  and  Supported  Product  List,  15  Aug 
97,  the  preferred  vendor  package  is  MS  Exchange.  It  appears  to  be  the  only  product  that  puts  TRADOC 
on  a  clear  migration  path  to  DMS  and  provides  the  required  extended  functionality.  HQ  TRADOC  (Fort 
Monroe)  is  actively  pursuing  its  own  migration  to  MS  Exchange  and  it  is  the  target  product  chosen  by 
15  of  16  TRADOC  DOIMs  for  support. 

DMS  compliant  products  use  electronic  messaging  (X.400)  and  directory  (X.500)  components  that 
have  undergone  DMS  conformance,  interoperability  and  compliance  certification  by  the  DISA  Joint 
Interoperability  Test  Center  (JITC).  At  this  writing,  DMS  compliance  testing  is  incomplete  and  an 
official  list  of  products  does  not  exist.  The  application  software  uses  a  client-server  architecture, 
meaning  modules  of  DMS  run  on  platforms  distributed  throughout  the  system  architecture.  Following 
are  the  various  platform  and  application  components  that  comprise  DMS.  Usually,  for  each  component, 
there  are  several  vendors  that  have  designed  compliant  products. 

MTAs:  Message  Transfer  Agents.  MTAs  route  messages  fi’om  the  source  to  its  destination.  DMS  uses 
three  levels  of  MTAs: 

SMTA:  Subordinate  Message  Transfer  Agent.  At  the  local  level  the  Subordinate  MTA  (SMTA) 
interfaces  directly  with  the  User  Agents  (UAs)  and  Message  Stores  (MSs)  and  routes  messages  locally  or 
upward  within  DMS.  SMTAs  are  collocated  with  the  MS  at  the  local  user's  server. 

IMTA:  Intermediate  Message  Transfer  Agent.  IMTAs  provide  base  access  and  switching. 

BMTA:  Backbone  Message  Transfer  Agent.  BMTAs  provide  for  global  message  switching. 
About  50  BMTAs  are  planned  to  be  installed  worldwide.  Both  IMTAs  and  BMTAs  are  dedicated  to 
message  switching,  are  hosted  on  HP  9000  Model  800  servers  and  may  be  thought  of  as  relays. 

MLA:  Mail  List  Agent.  Functionally  similar  to  AUTODIN  Address  Indicating  Groups/Collective 
Address  Designators.  Manages  mailing  lists  to  support  the  distribution  of  messages  tlnoughout  DMS. 
Messages  that  go  to  large  groups  of  users  are  routed  to  the  MLA  where  the  header  of  the  message  is 
expanded  to  include  the  address  of  each  recipient. 

MFI:  Multi-Function  Interpreter.  MFIs  convert  messages  from  one  protocol  to  another  and  allow  the 
DMS  to  share  messages  with  systems  which  are  not  X.400  compatible.  Within  the  DMS  the  MFI 
functions  as  the  MTA  and  appears  to  the  AUTODIN  as  a  Mode  1  terminal.  For  E-Mail  the  MFI  acts  as  a 
SMTP-to-  X.400  gateway. 

CAW:  Certification  Authority  Workstation.  Records  information  on  the  Fortezza  cards. 

MWS:  Management  Workstation.  The  MWS  provides  local  and  remote  control  and  monitoring  of  the 
DMS  components.  It  provides  configuration,  fault,  performance,  accounting  and  security  management 
capabilities  to  support  monitoring  and  control,  system  administration  and  customer  service.  The  MWS 
interfaces  to  the  DMS  components  using  the  SNMP  management  protocol. 

DSA:  Directory  System  Agent.  The  DMS  directory  system  stores  information  in  a  distributed, 
hierarchical  structure  known  as  the  Directory  Information  Tree  (DIT).  Entries  describe  users,  groups  or 
network  resources,  stored  in  three  formats:  X.400,  AUTODIN  and  SMTP.  The  Directory  User  Agent 
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(DUA)  is  the  application  which  provides  the  user  a  means  to  access  information  stored  in  the  directory. 
The  DUA  is  integrated  with  the  UA.  DSAs  are  geographically  distributed  and  are  also  hierarchically 
structured  into  root,  global,  regional  and  site  DSAs.  The  site  DSA  commimicates  with  a  network  of 
DSAs  to  satisfy  the  DUAs  request. 

MS:  Message  Store.  Stores  messages  much  like  a  mailbox.  Messages  are  submitted  through  the  MS. 
The  MS  will  reside  on  a  server  accessed  by  the  UA. 

PUA:  Profiling  User  Agent.  PUAs  provide  the  features  needed  to  handle  profiling  and  message 
dissernination  of  organizational  messages.  Profiles  and  distribution  information  are  built  for  a  given 
organization  and  activated  at  the  PUA.  Upon  receipt  of  a  message,  the  PUA  decrypts  the  message  and 
activates  the  profile.  The  profile  can  trigger  searches  for  key  words  in  the  subject  area  and  text,  as  well 
as  trigger  on  precedence.  If  the  profile  determines  a  "hit"  then  the  message  is  disseminated  based  on  the 
distribution  information  associated  with  the  profile.  The  PUA  can  reduce  bandwidth  requirements  by 
limiting  distribution  to  a  small  group  of  need-to-know  individuals. 

Base-Level  MWS:  The  Base-Level  Management  Work  Stations  provides  both  local  and  remote,  control 
and  rnonitoring  of  the  DMS  components.  It  provides  configuration,  fault,  performance,  accounting  and 
security  management  capabilities  to  support  monitoring  and  control,  system  administration  and  customer 
service.  The  MWS  interfaces  to  the  DMS  components  using  the  SNMP  management  protocol. 

UA:  User  Agent.  Desktop  graphical  user  interface  application  that  enables  users  to  create,  release  and 
receive  messages.  It  is  bundled  with  the  DUA  for  accessing  X.500  directory  services. 

Similar  to  the  DISN  system  architecture,  TRADOC  will  not  own  all  the  components  of  DMS. 
TRADOC  will  own  the  PCs  that  run  the  UA  software  and  the  servers  that  run  the  SMTA  software.  Since 
the  UA  resides  on  a  TRADOC  owned  platform,  TRADOC  PC  acquisitions  will  have  to  provide  certain 
features,  e.g.,  PCMCIA  readers  for  reading  security  data  from  a  FORTEZZA  card  and  sufficient  RAM  to 
run  Windows  operating  system.  These  features  were  discussed  in  paragraph  4.4.2. 5  regarding  personal 
level  platforms. 

Figure  27  shows  how  key  applications  are  distributed  in  the  DMS  client/server  architecture. 

See  also: 

5.3.1  Defense  Messaging  System  (DMSl 
For  more  information: 

http://www-tradoc.monroe.armv.mil/dcsim/dms/dms.htm 
http  ://www.momnouth.annv.mil/dms/ 
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To  Be  Funded  by  TRADOC 
andAimyPMO. 


Figure  27.  DMS  architecture 


4.4.3.2  Office  Automation 


•  u  objective  system  architecture,  all  TRADOC  action  officers  will  have  a  computing  platform 
with  access  to  an  office  automation  suite  suited  to  their  tasks.  As  in  the  baseline,  common  office 
automation  capabilities  will  include  word  processing,  spreadsheets,  graphics,  and  access  to  network 
services,  e.g.,  e-mail,  scheduling,  web  browsing  and  electronic  coordination.  Installations  are  likely  to 
use  a  mix  of  vendors'  office  automation  applications.  DOIMs  can  issue  lists  of  products  they  will 
support.  To  assist  DOIMs  in  enforcing  this  approach,  HQ  TRADOC  coordinated  and  issued  a 
memorandum,  SUBJECT:  TRADOC  FY98  Desktop  Computer  Preferred  and  Supported  Product  List,  15 
Aug  97,  stating  the  preferences  shown  in  Table  6. 

Table  6.  Preferred  Office  Automation  Applications 
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CATEGORY 

TRADOC 

PREFERRED  AND  SUPPORTED  DESKTOP 
SOFTWARE  AND  OPERATING  SYSTEM 

Office  Suite 

Full  Suite:  Microsoft  Office 

Word  Processing:  Word 

Spreadsheet:  Excel 

Presentations:  PowerPoint 

Data  Base:  Access 

Project  Management:  Project 

Office  Management 

Microsoft  Exchange 

Schedule-b  (2) 

Internet  Browser 
(Includes  FTP  and 
Newsgroups) 

MS  Explorer  (3) 

Forms 

FormFlow 

Multimedia  Authoring 

Asymetrix  Multimedia  Toolbook,  CBT  Edition 

Seciuity 

McAfee  W 

(1)  Must  be  DMS  compliant  and/or  upgradable  to  DMS  compliance. 

(2)  Provided  with  MS  Exchange  and  DMS-compliant  version. 

(3)  Provided  as  a  component  of  NT  Workstation  4.0. 

(4)  Available  for  download  at  httD://199.21 1.123.12/Vims/avims.html 

4.4.3.3  Videoteleconferencing 

TRADOC  will  make  increased  use  of  desktop  VTCs,  linking  selected  TRADOC  offices  and 
personal  level  users  into  a  command-wide  network,  with  access  to  users  outside  the  command.  The 
baseline  architecture,  installed  as  a  HQ  TRADOC  managed  initiative,  already  reaches  the  TRADOC 
leadership  (see  Figure  14).  Additional  nodes  will  be  added  through  distributed  acquisitions  as  network 
capacity  and  connectivity  make  it  feasible.  Not  only  will  connectivity  increase,  but  also  the  capabilities 
for  sharing  applications  via  standardized,  PC-based  DVTC  workstations.  VTC  and  DVTC  will  be 
enablers  for  electronic  coordination  of  TRADOC  products  and  electronic  collocation  as  part  of  new 
organizational  concepts.  Proliferation  of  DVTC  components  to  support  commimities  of  users,  e.g., 
combat  developers'  integrated  concept  teams  and  integrated  product  teams,  will  increase.  VTC  will  be  a 
necessary  enabler  of  distance  learning  also,  and  will  be  inside  Classroom  (see  paragraph  4.4.4.11. 

4.4.3.4  Printing 

During  1997,  TRADOC  initiated  an  effort  to  ensure  connectivity  fi’om  the  installations'  CANs  to 
their  supportiiig  Defense  Automated  Printing  Service  (DAPS)  service  centers.  For  most  installations, 
this  coimectivity  is  now  part  of  the  baseline  architecture.  It  enables  CAN  users  to  forward  files, 
containing  formatted  documents,  to  the  DAPS  for  printing.  Additionally,  DAPS  is  investing  in  WAN 
connectivity  to  link  its  distributed  service  centers  and  printing  plants.  DAPS  can  use  digital  files  to 
produce  high  quality  first  generation  copies  on  their  automated  printing  equipment.  In  the  objective 
architecture,  TRADOC  and  DAPS  will  combine  the  capabilities  of  electronic  authoring,  digital  file 
transfer,  distributed  file  servers  and  printing  equipment,  along  with  an  automated  system  for  submitting 
and  managing  print  work  orders,  into  new  approaches  for  printing  and  distributing  our  publications. 

=>  Print-on-demand.  TRADOC  organizations  will  provide  files  to  DAPS  for  printing  For  example, 
TRADOC  service  schools  will  electronically  forward  student  hand-outs,  student  texts,  and  extracts  from 
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TRADOC  publications.  DAPS  will  use  the  files  to  print  only  in  the  quantities  immediately  required  and 
will  store  them  for  future  use.  As  coiirses  are  scheduled  to  begin,  schools  can  request  additional 
printings.  TRADOC  will  save  warehouse  space,  labor,  and  printing  costs,  and  will  improve  the  currency 
of  printed  publications. 

=>  Distribute  and  print.  DAPS  can  distribute  files  electronically  among  its  service  outlets.  A  file 
provided  by  a  TRADOC  organization  at  one  location  can  be  quickly  and  cheaply  sent  to  many  other 
locations.  Printing  of  the  file  can  occur  in  many  places  distant  from  where  it  was  authored,  but  closer  to 
the  site  where  the  documents  will  be  used.  In  cases  where  TRADOC  must  distribute  publications  (e.g., 
schools  distribute  instructional  material  to  reserve  components),  TRADOC  will  save  mail  and  storage 
costs.  This  distribute  and  print  approach  can  be  combined  with  print  on  demand  to  realize  more 
efficiencies  for  TRADOC  and  the  users  of  TRADOC  products.  DAPS  will  store  files  of  TRADOC 
products  which  will  be  available  for  print  on  demand  at  any  DAPS  outlet  by  any  customer. 

=>  Tailored  products.  Since  DAPS  will  be  working  from  digital  input,  the  output  can  be  tailored  as 
required  to  suit  the  immediate  requirement.  Users  can  demand  any  media  DAPS  is  capable  of  producing, 
including  paper,  disks  and  CD  ROM.  Documents  can  be  collated  and  packaged  for  specific  uses,  e.g., 
course  book  sets  can  be  assembled  from  diverse  sources  and  bundled  for  distribution  to  individual 
students.  Instructors  can  tailor  course  sets  even  further  by  requesting  relevant  chapters  from  TRADOC 
regulations  or  doctrine,  and  having  them  collated  into  a  new  book  for  use  in  a  course,  with  assmance 
they  are  using  the  latest  document  sources. 

4.4.4  Mission  applications 

As  in  the  baseline  system  architecture,  TRADOC  will  use  software  from  a 
variety  of  mostly  non-developmental  sources  as  its  mission  applications.  COTS 
applications  will  provide  much  of  the  capability  needed,  although  some 
customization  of  applications,  e.g.,  user  interfaces,  database  structure  or  report 
generation,  may  be  required.  DoD  and  Army  materiel  developers  will  provide 
standardized  GOTS  applications  for  other  missions,  e.g.,  STMCOM  for 
simulations  and  PEO  STAMIS  for  installation  management.  Consistent  with  the 
categories  used  throughout  TPRISM,  this  section  is  organized  into  paragraphs  on 
training,  M&S  and  installation  management  applications. 


Mission 

Applications 


Support 

Applications 

Platforms 

External 

Environment 


4.4.4.1  Training  Applications 

In  the  objective  environment,  MIS  to  manage  training  will  have  been  consolidated  into  several  key 
applications.  All  rely  on  ATDL  (see  paragraph  4.4. 1.1.2)  as  an  external  source  of  training  information. 
All  will  be  redesigned  to  share  data  in  a  client-server  architecture  and  make  greater  use  of  shared  data 
and  processing  capabilities.  The  target  architectures  are  described  in  the  Army  Training  Information 
Management  Program.  The  objective  architecture  is  depicted  Figure  28. 

See  also: 

Appendix  C:  Mission  Applications 

For  more  information: 
http://www.atimp.armv.mil/ 
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Develop  METL 


Plan  Organizational 
Training 


Execute  Organizational! 
Training 


Prepare  Organizational 
Assessment 


Administer  ' 

Training  Institution 


Provide  Student 
Administration 


Provide  Institutional 
Instruction 


Conduct  CTC  Operations 


Support  Institutional 
Instruction 
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Training _ 


Develop  Training 
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Figure  28.  Migration  of  Training  Mission  Applications 


There  will  be  widespread  use  of  automation  by  training  developers  in  preparing  training  materials, 
including  interactive  courseware  and  other  distributed  learning  products.  DCST  anticipates  this  function 
will  be  accomplished  using  a  suite  of  COTS  tools.  For  example,  the  training  developer's  toolkit  might 
include: 

•  Integrated  Office  Automation  Suite:  (Word  Processor,  Spreadsheet,  &  Graphics) 

•  HTML  Editor 

•  Hypertext  Editor 

•  Multimedia  Production  Creator  (e.g.,  Toolbook  II) 

•  Graphics  Editing  Package  (e.g.,  CorelDraw) 

Instructors  will  routinely  incorporate  automated  tools  into  classroom  instruction.  Institutional 
classrooms  will  be  designed  to  leverage  technology  although  not  every  classroom  will  have  maximum 
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technological  capabilities.  Schools  will  modernize  those  classrooms  which  technology  can  provide  the 
greatest  return  on  effectiveness  and  efficiency.  In  TRADOC's  objective  system  architecture,  these  new 
approaches  to  training  will  be  enabled  by  a  project  called  Classroom  XXI.  In  this  concept,  the  classroom 
will  harness  all  the  components  discussed  above  (WANs,  CANs,  LANs,  computing  platforms,  and  VTC) 
to  enhance  TRADOC's  execution  of  its  training  mission.  In  turn,  Classroom  ;^I  is  a  major  functional 
driver  shaping  the  objective  system  architecture  for  TRADOC's  common  user  networks.  Classroom  XXI 
must  also  integrate  mission  applications  unique  to  the  training  domain,  e.g.,  computer  assisted 
instruction,  automated  student  response  systems,  multimedia  courseware  and,  at  the  highest  level  of 
maturity,  interactive  models  and  simulations  and  virtual  reality. 

There  will  be  five  levels  of  IS  capabilities  in  Classroom  XXI  facilities.  Each  level  cumulates  the 
capabilities  of  the  lower  levels. 

=>  Level  1,  the  instructor  has  a  multimedia  workstation  and  controls  the  pace  of  the  instruction.  The 
workstation  will  be  capable  of  working  with  videotapes  and  cable  television  access,  an  electronic  white 
board  and  projection  system.  The  students  will  participate  in  automated  response  systems. 

=>  Level  2  adds  capabilities  to  move  toward  student  controlled  learning.  In  addition  to  the 
instmctor's  multimedia  workstation,  students  will  have  individual  multimedia  workstations  coimected  to 
the  instructor  via  a  LAN.  The  student  response  system  will  be  integrated  into  the  student  software. 

=>  Level  3  connects  both  the  student  and  instructor  to  resources  outside  the  immediate  training 
environment  to  enable  distance  learning,  e.g.,  VTC  and  video  teletraining. 

=>  Level  4  allows  the  student  to  participate  in  simulated  exercises  via  interactive  aeeess  to  M&S. 

=>  Level  5,  though  undefined,  will  include  virtual  reality  capabilities. 

Additionally,  Digitized  Training  Access  Centers  (DTAC)  are  a  key  element  of  the  Classroom  XXI 
environment  and  the  distance  learning  infrastructure.  It  is  envisioned  that  each  installation  will  have  a 
DTAC  providing  a  central  service  for  multiple  classrooms.  DTAC  services  include  cormectivity,  transfer 
and  storage  of  proponent  training  materials,  dial-in  or  remote  access  capability  and  centralized 
administration  and  maintenance.  The  DTAC  serves  as  the  central  hub  for  the  school's  Classroom  XXI 
network  and  the  gateway  to  the  distance  learning  network.  The  DTAC  allows  users  to  share  information 
and  resources.  The  DTAC  must  be  connected  to  the  CAN  and  the  distance  learning  gateway.  DTAC 
contains  servers  that  provide  centralized  storage  of  the  school's  digitized  products.  These  products 
include  training  presentations,  training  support  materials,  electronic  technical  manuals,  and  videos. 

Users  will  be  able  to  access  material  from  anj^here  on  the  network.  A  dial-in  capability  will  provide  a 
central  point  for  external  users  to  access  training  materials  stored  in  the  DTAC's  servers.  From  remote 
locations,  users  will  be  able  to  dial-in  and  log  on  the  network  to  access  training  and  reference  materials. 

DCST's  draft  TRADOC  Classroom  XXI  Installation  Master  Plan  provides  further  descriptions  of 
capabilities  and  recommended  equipment  configurations. 

See  also: 

5.4.2  ATIMP 

5.4.3  Classroom  XXI 


For  more  information: 

http://www-dcst.monroe.armv.mil/adlD/adlp.htm 

4.4.4.2  Models  and  Simulations  (M&S) 

M&S  in  the  objective  architecture  will  become  federations  among  live,  virtual,  and  constructive 
simulation  systems  that  realistically  portray  warfighting  operations.  Integrated  M&S  tool  suites  will 
support  exercise  requirements  definition,  scenario  design,  database  development,  exercise  control, 
critical  event  generation,  after  action  review,  and  feedback.  The  distinction  among  separate  M&S 


53 


applications  will  blur  as  the  infrastructure  and  architecture  for  M&S  becomes  standardized  and  as  M&S 
developers  adopt  common  architectures  in  which  battlefield  "objects"  are  shared  among  M&S 
applications.  In  the  target  architecture,  distinct  M&S  applications  will  persist  in  accordance  with  users' 
requirements  for  differing  levels  of  resolution,  echelons,  functional  areas,  and  human  interaction. 

4.4.4.2.1  Migration  to  High  Level  Architecture 

In  the  baseline  and  target  architectures,  the  protocols  for  linking  M&S  are  distributed  interactive 
simulation  (DIS)  and  Aggregate  Level  Simulation  Protocol  (ALSP).  In  the  objective  architecture,  the 
High  Level  Architecture  ^LA),  as  prescribed  by  the  Defense  Modeling  and  Simulation  Office,  will 
supersede  both  ALSP  and  DIS.  HLA  is  being  developed  by  DoD  to  provide  a  common  framework  for  all 
DoD  simulation.  To  prove  that  the  HLA  is  a  viable  concept,  DoD  is  currently  sponsoring  prototype 
implementations.  It  is  DoD  policy  that  all  M&S  must  comply  with  the  HLA,  receive  a  waiver,  or  be 
retired  by  2001  (see  paragraph  6.3.41. 

DIS  is  a  set  of  communication  standards  and  protocols  for  interaction  among  distributed  virtual 
M&S.  Among  DIS  compliant  systems,  there  is  no  central  computer  for  event  scheduling  or  conflict 
resolution.  Each  autonomous  simulation  node  is  responsible  for  maintaining  the  state  of  one  or  more 
simulation  entities  and  broadcasting  changes  in  their  states.  An  example  DIS  environment  would  be 
vehicle  simulators  at  several  sites  manned  by  crew  members.  Each  simulator  is  under  the  full  control  of 
the  individual  vehicle  commander  and  communicates  with  other  collocated  vehicle  commanders  through 
a  LAN.  Through  the  WAN,  vehicle  crews  from  multiple  sites  can  communicate  with  each  other  and 
participate  in  a  common  exercise,  fully  interactive  with  simulators  at  each  site.  There  will  continue  to  be 
DIS  exercises  run  during  the  period  of  transition  to  HLA.  Also,  there  are  DIS  to  HLA  conversions  being 
developed  to  support  DIS  based  federates  used  in  prototype  HLA  federations,  which  suggest  that 
commercial  products  will  become  available  to  ease  the  migration  from  DIS  to  HLA. 

ALSP  is  a  protocol  designed  to  permit  multiple,  existing  (legacy)  warfare  simulations  to  interact 
with  each  other  over  networks.  ALSP  originated  with  the  need  to  provide  more  exercise  realism  through 
the  interaction  of  various  service  owned  simulations,  e.g.,  the  Marine  Air  Ground  Task  Force  Tactical 
Warfare  Simulation,  Air  Force's  Air  Warfare  Simulation,  the  Army's  CBS  and  TACSIM,  and  the  Navy's 
Research,  Evaluation,  and  Systems  Analysis  model.  The  concept  of  ALSP  is  to  allow  each  simulation  to 
control  its  own  objects,  as  originally  designed,  but  to  share  information  about  its  operation  with  other 
models. 

Standardized  architecture  will  enable  experimentation  and  training  with  selected  combinations  of 
the  live,  virtual,  and  constructive  M&S,  with  interfaces  to  real  world  C4I  systems.  The  objective 
architecture  for  TRADOC  M&S  users  includes  new  Army  and  joint  applications  grouped  under  the 
Combined  Arms  Tactical  Trainer  (CATT),  Joint  Warfare  System  (JWARS)  and  Warfighters'  Simulation 
(WARSIM)  2000  programs.  TRADOC's  objective  architecture  also  includes  a  set  of  reconfigurable 
simulators  the  Battle  Labs,  still  in  the  planning  stages. 

4.4.4.2.2  Battle  Lab  Reconfigurable  Simulators 

In  the  objective  architecture,  Battle  Labs  throughout  TRADOC  will  have  reconfigurable  simulators 
for  analyzing  and  experimenting  with  new  concepts  for  Force  XXI  and  new  requirements  for  doctrine, 
training,  leader  development,  organizations  and  materiel.  These  tools  will  extend  the  use  of  simulators 
and  simulations,  which  is  currently  dominated  by  TEMO  applications,  and  will  help  involve  the 
warfighter  in  the  mat,riel  acquisition  process. 

A  reconfigurable  simulator  will  be  a  virtual,  man-in-the-loop  simulator  which  can  be  rapidly 
reconfigured  to  represent,  to  varying  levels  of  fidelity,  current  and  future  configurations  of  a  given 
vehicle  or  weapon  system  platform.  These  simulators  will  use  a  common  core  object  oriented  software 
architecture  but  will  have  modules  specialized  for  representing  specific  systems,  e.g.,  tracked  and 
wheeled  ground  vehicles;  rotary  wing  aircraft;  command,  control,  communication,  computer  and 
intelligence  systems;  or  dismounted  infantry  soldiers.  The  Battle  Labs'  reconfigurable  simulators  will  be 
interoperable  with  the  Close  Combat  Tactical  Trainer  (CCTT)  and  compatible  with  the  HLA  standards. 
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The  precise  performance  specifications  are  still  being  worked  by  the  combat  developers. 

4.4.4.2.3  Combined  Arms  Tactical  Trainer  (CATT) 

CATT  will  be  a  family  of  virtual  simulators.  CATT  will  be  geographically  dispersed  at  TRADOC 
schools  and  tactical  units.  CATT  will  provide  commanders,  up  to  battalion  task  force  level,  the 
opportunity  to  train  in  a  realistic,  force-on-force,  virtual  battlefield  environment.  CATT  uses  a 
combination  of  manned  simulators,  workstations,  semi-automated  forces,  and  DIS  technology,  for  both 
proficiency  and  sustainment  training  of  selected  individual,  crew,  collective,  staff,  and  combined  arms 
tasks.  By  linking  functional  modules,  combined  arms  exercises  can  be  done  using  CATT.  Linkage  is 
facilitated  by  use  of  DIS  technology  in  all  CATT  modules.  The  five  CATT  modules  are: 

•  The  Close  Combat  Tactical  Trainer  (CCTT). 

•  The  Aviation  Combined  Arms  Tactical  Trainer  (AVCATT). 

•  The  Air  Defense  Combined  Arms  Tactical  Trainer  (ADCATT). 

•  The  Fire  Support  Combined  Arms  Tactical  Trainer  (FSCATT-Phase  II). 

•  The  Engineer  Combined  Arms  Tactical  Trainer  (ENCATT). 

CATT  uses  many  IS  components  which  can  be  grouped  into  two  categories  -  manned  simulators  and 
the  CATT  core  environment.  The  manned  simulators  are  vehicle  and  weapon  system  simulators.  As 
proponents  assess  their  task  based  training  requirements,  manned  simulators  will  exhibit  the  required 
fidelity  to  train  individual,  crew,  collective,  and  combined  arms  tasks.  The  CATT  core  environment 
consists  of  elements  common  to  all  proponent  modules,  e.g.,  semi-automated  forces  (SAP),  terrain 
databases,  rapid  database  generation  tools,  and  the  Standard  Army  After  Action  Review  System 
(STAARS).  SAF  allows  a  single  operator  to  create  and  control  the  actions  of  a  number  of  virtual 
combatants.  Each  SAF  entity  (tank,  helicopter,  etc.)  or  small  unit  executes  realistic  battlefield  behaviors 
in  response  to  the  operator's  controls.  There  is  an  initiative  underway,  called  OneSAF,  to  combine 
several  SAF  applications  into  one  for  shared  use.  It  will  create  a  wide  variety  of  OPFOR  and  BLUFOR 
vehicles  and  imits  which  units  can  train  against  or  with. 

Migration  to  the  objective  architecture  will  be  phased,  with  the  CCTT  being  fielded  first.  CCTT  will 
train  more  than  80%  of  the  Armor,  Cavalry  and  Mechanized  Infantry  Platoon  and  Company/Team 
collective  tasks.  CCTT  is  the  first  fully  DIS  compliant  training  system  and  consists  of  networked, 
manned  vehicle  simulators  for  the  MlAl,  M1A2,  M2/3A2,  FIST-V,  M113A3,  and  the  HMMWV.  These 
work  in  combination  with  SAF  and  STAARS. 

4.4.4.2.4  Joint  Warfare  System 

The  Joint  Warfare  System  (JWARS)  will  be  an  HLA  compliant  system  that  includes  modules  for 
many  of  the  analytical  functions  currently  performed  by  TACWAR,  Eagle,  VIC  and  CASTFOREM. 
JWARS  will  include  representation  of  all  joint  warfare  mission  areas.  JWARS  will  be  a  closed-form, 
constructive  simulation  of  multi-sided,  joint  warfare  used  throughout  the  DoD  and  services.  JWARS  will 
not  be  interactive,  support  real-time  mission  execution,  or  be  lifted  directly  to  real-world  systems. 

The  Army  Warfare  System  (AWARS)  will  merge  VIC  and  Eagle  and  become  the  operational  land 
warfare  representation  in  JWARS.  The  migration  toward  the  objective  architecture  for  JWARS  and  other 
ACR  applications  is  depicted  in  Figure  29.  Planning  for  the  objective  architecture  is  based  on  2005  for 
full  operational  capability. 
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Baseline 


Target 


Objective 


TACWAR  Tactical  Warfare 

VIC  -  Vector  in  Command 

AWARS  -  Army  Warfare  System 

JWARS  -  Joint  Warfare  System 

TAFSM  -  Target  Ac  quisiti  on  Fire  Support  Model 


AFAM  -  Artillery  Functional  Area  Model 

EADSIM  -  Extended  Air  Defense  Simulation /Test  Bed 

NAM  -  N  etwork  Assessment  Model 

TSCAM  -  Team  Signal  Communication  Analysis  Model 

CSSFAM  -  C  ombat  Service  Support  F  amily  of  Analytical  Model; 


Figure  29.  Migration  of  ACR  M&S 


4AA.2.5  Warfighters'  Simulation  (WARSIM)  2000 

WARSIM  2000  is  the  Army's  objective  architecture  M&S  application  for  command  and  staff 
training.  It  is  scheduled  for  fielding  in  2000.  It  will  train  Army  battle  staffs  at  all  echelons,  fi'om 
Battalion  to  Echelons  Above  Corps  (EAC).  It  will  replace  the  baseline  architecture  of  FAMSIM 
applications.  In  the  target  architecture,  WARSIM  will  integrate  M&S  applications  using  ALSP  and  will 
be  DIS  compliant.  WARSIM  2000's  design  will  allow  command  posts  to  interact  with  the  simulation 
using  their  TOE  equipment  so  that  they  can  train  in  the  field,  not  just  in  simulation  centers.  As  shown  in 
Figure  30.  several  baseline  battle  staff  simulations  will  remain  in  the  architecture  until  replaced  by 
WARSIM  2000. 

TRADOC  schools  will  use  WARSIM  2000  to  conduct  leader  training  and  CPXs  for  students  at 
officer  basic  and  advanced  courses  and  NCO  advanced  courses.  The  individual  institutional  strategy  will 
determine  whether  a  school  needs  dedicated  systems  or  can  link  to  a  supporting  Regional  Simulation 
Center.  Schools  will  use  their  personal  level  computers  and  networks  in  lieu  of  TOE  battle  command 
systems  as  their  interface  for  WARSIM  2000.  All  schools  will  be  able  to  link  their  training  to  exercises 
being  conducted  by  field  units  or  other  schools.  For  example,  students  at  the  Battle  Staff  NCO  course  or 
CAS  3  could  represent  an  additional  brigade  in  a  division  level  exercise. 

WARSIM  2000  is  the  Army  component  of  the  Joint  Simulation  System  (JSIMS),  which  will 
provide  command  and  staff  training  to  all  of  the  services.  It  will  provide  a  core  of  common 
representations  for  air/space,  land,  and  sea  warfare  to  support  training  for  unified/specified  commands 
and  Joint  Task  Forces  in  all  phases  of  military  operations.  It  is  scheduled  for  initial  operational 
capability  in  December  1999. 

The  WARSIM  Intelligence  Module  (WIM)  will  replace  the  TACSIM. 
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CSSTSS  will  continue  to  be  used  in  the  objective  architecture.  Its  functionality  was  described  as 
part  of  the  baseline  architecture.  CSSTSS  architecture  will  be  brought  into  conformance  with  WARSIM 
standards. 


EAC 


CORPS/ 

DMStON 


ERMAOE/ 

BATTALfON 


COMPANY/ 

TEAM 


Figure  30.  Migration  of  battle  staff  M&S 


4A.4.3  Installation  Management  Applications 

In  the  objective  system  architecture,  TRADOC  will  employ  a  standardized  library  of  installation 
management  applications,  built  on  a  common  operating  environment,  with  well  encapsulated  modules 
that  maximize  the  reuse  of  common  capabilities  and  shared  data.  Each  installation  will  have  an 
integrated  logical  database  populated  with  standardized  database  schemata  and  data  elements.  As 
necessary,  HQ  TRADOC  will  have  the  MACOM  version  of  the  database. 

This  vision  of  the  objective  architecture  is  beyond  the  capabilities  of  applications  that  are  currently 
planned  and  funded.  Nevertheless,  there  are  significant  actions  imderway  that  will  change  the 
architecture  for  installation  management  applications.  Described  in  the  sub-paragraphs  below  are 
modernization  efforts  impacting  the  replacement  of  TRADOC's  ISMs  and  the  extension  of  applications 
in  several  fimctional  areas. 

Most  installation  management  applications  are  program  managed  by  organizations  external  to 
TRADOC.  TRADOC  must  integrate  the  mission  applications  into  its  information  architecture.  This 
means  ensuring  that  the  information  exchanges  required  to  implement  the  functional  process  are 
supported  with  network  connectivity  at  the  LAN,  CAN  and  WAN  levels  and  that  platforms  are 
distributed  as  necessary  to  provide  processing  power  at  the  users'  locations.  TRADOC  must  work  with 
external  program  managers  to  insert  the  new  application  into  available  infrastructure,  identify  gaps  in 
required  infrastructure  and  plan  modernization  required  to  fill  the  gaps. 

4.4.4.3.1  Replacement  of  ISMs 

TRADOC's  own  ISM  have  been,  or  will  be,  replaced  by  applications  from  a  variety  of  sources,  but 
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primarily  by  the  SBIS  and  ITP  ISM  programs.  Table  7  provides  an  overview  of  the  objective 
replacement  applications,  and  their  status.  Army  funding  to  support  development,  fielding  and  post 
deployment  software  support  (PDSS)  of  many  installation  management  applications  will  be  terminated 
after  FY  98.  Even  so,  applications  fielded  as  SBIS  and  ITP  modules  are  anticipated  to  be  part  of 
TRADOC's  target  system  architecture  for  many  years.  Appendix  C  provides  a  complete  list  and  brief 
description  of  applications  in  the  SBIS,  ITP  and  several  other  Army  programs  for  standardized 
applications. 

See  also: 

4A.2.2  Platforms— Mission  Level 

5.2.2  SBIS 

5.2.3  ITP 

5.4.5. 1  Installation  Support  Modules 
For  more  information: 

http://www-tradoc.armv.mil/dcsim/v2k/restrict/v2k-ais/v2k-ais.html 

4.4.4.3.2  Personnel  Management 

DoD  operating  level  Civilian  Personnel  Offices  are  being  redesi^ed  to  adapt  to  resource  reductions. 
Army  has  established  seven  geographically  based  regions  in  the  continental  United  States  and  three 
overseas.  Regional  centers  will  provide  services  that  do  not  require  face-to-face  interaction.  Small 
on-site  staffs  will  remain  at  TRADOC  installations  to  serve  as  part  of  the  management  team  and  provide 
advice  to  the  commanders.  IS  support  is  required  to  implement  the  new  organization  and  process.  DoD 
is  developing  the  objective  system.  It  will  interface  with  other  systems,  such  as  payroll,  to  share 
information  vertically  and  horizontally  across  the  DoD.  It  must  be  accessible  to  managers,  supervisors, 
and  employees  for  information  update  and  retrieval.  It  will  incorporate  electronic  forms  processing  and 
coordination  capability  for  customer  organizations  and  the  personnel  office.  Network  servers,  among 
other  tasks,  provide  electronic  processing  of  personnel  action  requests,  position  descriptions,  position 
applications,  reduction-in-force  actions,  and  retirement  applications.  \\^le  the  objective  system  is  being 
developed,  a  hardware  and  communications  infrastructure  is  being  installed,  within  civilian  personnel 
offices,  to  operate  under  the  current  Defense  Civilian  Personnel  Data  System  (DCPDS)  in  support  of 
regionalization  efforts.  The  DoD  selected  Oracle  Human  Resources  (Oracle  HR),  a  commercial 
off-the-shelf  (COTS)  product  as  the  software  environment  for  the  modem  system.  A  collection  of 
Personnel  Process  Improvements  (PPI),  called  the  Integrated  PPI  Suite,  provides  interim  automation 
support  for  regionalization  prior  to  deployment  of  the  modem  system.  The  fimction  of  the  Suite  will  be 
migrated  to  the  objective  application.  The  objective  system  will  be  fielded  in  four  phases  to  reach  its 
objective  architecture: 

(I)  Proof  of  Concept  which  includes  a  demonstration  package  and  MAISRC  satisfaction. 

(II)  System  Foundation  which  includes  DoD  organizational  stmcture,  position  hierarchy  and 
system  security. 

(III)  Basic  Persoimel  Applications  which  includes  recmiting  and  staffing,  basic  pay  and 
benefits,  and  appraisal  and  performance  and; 

(IV)  Additional  Personnel  Applications  which  include  separations  and  retirement;  change  in 
appointing  office;  awards  and  employee  relations. 

4.4.4.3.3  MWR  Management 

The  objective  architecture  includes  an  integrated  MIS  for  managing  MWR  fimctions.  The 
MWRMIS  will  be  an  integrated  suite  of  applications.  The  applications  are  fielded  separately.  Some  are 
already  fielded  while  others  are  still  in  development.  In  the  objective  architecture,  the  modules  will  be 
integrated  and  networked,  with  links  to  include  MACOMs,  Defense  Finance  and  Accoimting  System 
and  the  Army  Community  and  Family  Support  Center  at  HQDA.  Individual  modules  are  listed  in 
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Appendix  B.  DCSBOS  has  identified  the  user  locations  that  require  CAN  connections  on  each 
TRADOC  installation.  MWRMIS  applications  are  PC  based,  and  in  varying  degrees  of  migration  toward 
JTA-Armv  compliance. 


Table  7.  TRADOC  ISM  Replacements 


TRADOC  ISM 


REPLACEMENT 

APPLICATION 


STATUS 


AVLS/WOMS 


Eliminate.  Will  use 
FORSCOM  system 


BATCH  MIL  PER 


DA  ISM  -  CIF 


AVAILABLE 


CIV  PERS  INQ 


DD1556TNG 


NONE  REQUIRED 


TRAIN 


FIELDED 


DD1556  TNG  HST 


TRAIN 


FIELDED 


DENTAL  MGT 


DAISM-DENTRAD 


AVAILABLE 


ENL  STU  ENTAC 


INPROCESS 


DA  ISM  -  SECCLEAR 


DA  ISM  -  INPROC 


lOT&E:  5/96 


FIELDED 


INST  CLEARANCE 


DAISM-OUTPROC 


FIELDED 


SIDPERS-3 


TESTING 


ORDERS 


SIDPERS-3 


TESTING 


OUTPROCESS 


DAISM-OUTPROC 


FIELDED 


POST  LOCATOR 


DAISM-PERSLOC 


FIELDED 


PROPERTY  BOOK 


SPBS-R 


FIELDED 


RAIDERS 


SPBS-R 


FIELDED 


REASSIGN 


SIDPERS-3 


TESTING 


RECORDS  INQ 


RECORDS  MGT 


SIDPERS-3 


TESTING 


SIDPERS-3 


TESTING 


SECURITY  MGT 


CCF:  "SOI" 


TESTING 


STD  INSTL  BUDGET 
SYSTEMS 


DCAS 


FIELDED 


SPECIAL  DUTY 


SIDPERS-3 


TESTING 


STATION  UNIQUE 


UIC/DoDAAC 


VEHICLE  REGIST 


MPMIS-RACS 


FIELDED 


*  REQUIRED  ONLY  IF  OTHER  TRADOC  ISMs  ARE  RETAINED. 

4.4.5  System  Architecture  Report  Card 

Comparing  characteristics  of  the  baseline  to  the  objective  system  architecture  shows  that  TRADOC 
has  significant  IS  modernization  tasks  ahead.  It  is  worth  noting  that  TRADOC  is  not  unique  in  this 
position.  Nearly  any  organization,  public  or  private,  of  TRADOC's  size,  distribution  and  complexity  that 
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has  an  open  standards  based  architecture  as  its  objective  will  find  significant  shortcomings  in  its 
baseline. 

Networking  components  are  key  enablers  for  TRADOC's  modernization.  By  leveraging  DoD 
investments,  TRADOC  has  created  serviceable  WAN  coverage.  TRADOC  will  need  higher  bandwidth 
access  to  WANs,  but  not  a  significantly  different  architecture.  At  14  of  16  installations,  TRADOC 
achieved  a  baseline  infrastructure  capability  for  CANs  and  WAN  access  consisting  of  a  lOOmbs  FDDI 
backbone  with  lOmbs  connection  tails  to  the  highest  priority  buildings.  This  baseline  infrastructure 
accommodates  most  data  transfer,  but  does  not  support  the  higher  bandwidth  requirements  of  video  or 
distributed  simulations  required  by  the  ADLP,  synthetic  environment,  and  other  Army-level  projects. 
Most  high  priority  user  locations  have  open  architecture  LANs  that  will  support  TCP/IP  traffic.  Open 
connectivity  is  not  universal  however  and  will  have  to  be  expanded  to  reach  more  user  locations,  to 
increase  coordination  capabilities  and  to  enable  employment  of  new  platforms  and  applications,  e.g., 
SBIS  and  ITP.  Network  security  components,  at  WAN,  CAN  and  LAN  level,  are  inadequate  to  coimter 
conceivable  threats. 

TRADOC  needs  to  modernize  its  server  platforms.  We  need  servers  that  comply  with  the  technical 
architecture  and  that  are  part  of  a  robust  network  that  puts  computing  power  and  data  manipulation 
capabilities  at  the  user  level.  As  any  large  organization,  TRADOC  is  running  hard  to  keep  pace  with 
platform  hardware  evolution  at  the  user,  or  client,  level.  That  pace  cannot  slow  down  if  TRADOC  is  to 
employ  software  with  a  client-server  architecture  and  graphic  user  interface.  There  are  about  35,000  PCs 
in  use  in  TRADOC.  Almost  as  many  are  Intel  386  and  below  as  are  486  and  above.  386  and  below  is  an 
inadequate  processing  platform  for  working  with  TRADOC's  information  based  products.  Sub-standard 
platforms,  combined  with  inadequate  funds  for  software  upgrades,  necessitate  our  continued  use  of 
mixed  generations  of  networking  services  and  office  automation  applications  that  impede  fi'ee  exchange 
of  information. 

TRADOC  must  proliferate  the  DMS  throughout  the  command.  Again,  this  implies  the  right 
networking  and  platforms,  as  well  as  the  application  software.  TRADOC  can  leverage  partial  fieldings 
of  DMS  by  DoD  resources,  but  has  a  substantial  role  to  play  in  proliferating  it  to  the  majority  of 
TRADOC  users. 

Many  TRADOC  mission  applications  were  developed  for  use  in  an  older  architecture.  They  still 
provide  required  functionality,  but  they  need  to  be  modernized  to  operate  in  an  open  architecture  and  in 
the  new  millennium,  to  exploit  the  possibilities  of  newer  software  architectural  approaches,  and  to 
exploit  newly  understood  opportunities  for  inserting  information  technology  into  operational  processes. 
Many  MIS  applications  for  installation  management,  and  some  for  training,  are  being  developed  but 
nonetheless  appear  to  be  at  risk  for  fielding  to  TRADOC  installations.  Under  funded  PDSS  for  MIS  will 
hinder  the  migration  of  fielded  capabilities  to  an  open  architecture.  TRADOC  has  lost  most  of  its 
internal  MIS  development  capability  to  make  the  fixes.  Without  external  efforts  to  leverage,  TRADOC's 
modernization  task  for  MIS  type  applications  will  be  short  of  operational  requirements  and  realistic 
opportunities  for  process  improvements.  Regarding  other  mission  applications,  particularly  Classroom 
)KI  and  the  synthetic  environment,  TRADOC  is  only  at  the  very  beginning  of  achieving  the  vision. 
Underneath  all  applications  is  an  increased  dependence  on  a  robust  network  to  satisfy  the  operational 
concept. 

Resourcing  is  a  limiting  factor  in  modernizing  the  system  architecture  and  making  the  fixes 
discussed  above.  In  the  commander  assessments  for  FY98,  seven  TRADOC  installation  commanders 
specifically  included  information  technology  modernization  as  an  under  resourced  deficiency. 
TRADOC's  key  enabling  investments  have  emphasized  the  insertion  of  IS  into  functional  processes,  but 
the  ideas  quickly  absorb  the  available  OPA  funds  command-wide.  The  next  section  will  describe  the 
various  efforts  underway,  using  TRADOC  resources  and  other  organizations'  resources,  to  modernize 
TRADOC's  system  architecture  consistently  with  the  vision. 
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Chapter  Five:  IS  Modernization  Projects 

This  chapter  looks  at  specific  projects  that  will  advance  TRADOC's  baseline  system  architecture 
closer  to  the  objective  architecture  described  in  Chapter  4.  This  chapter  includes  key  projects,  but  should 
not  be  considered  exhaustive.  There  are  other  important  efforts  not  described  in  TPRISM,  although  all 
such  efforts  must  be  architecturally  consistent  with  TPRISM.  After  describing  specific  key  projects,  this 
chapter  briefly  discusses  resources  and  organizational  responsibilities  for  IS  modernization  that  are  not 
specific  to  one  project.  For  a  description  of  the  approval  process  that  governs  TRADOC  initiated  IS 
modernization  projects,  see  TRADOC  Pamphlet  25-72.  scheduled  for  publication  1Q98. 

The  project  descriptions  in  this  chapter  are  categorized  according  to  the  TRM  (see  Figme  31.  as  was 
the  description  of  the  system  architecture  in  Chapter  4.  Table  8  provides  an  alternative  categorization  to 
emphasize  the  relationships  between  oiu  strategic  IM  goals  and  IS  modernization  projects.  Recall,  from 
Table  1.  that  TRADOC's  IM  goals  most  relevant  to  IS  modernization  are: 

•  improve  interoperability  of  TRADOC's  IS 

•  modernize  the  IMA  infrastructure  to  meet  mission  requirements 

•  ineorporate  information  technology  in  support  of  TRADOC  business  processes 


Table  8.  Crosswalk  between  IM  goals  and  projects 


TRADOC  IM  Goal 

Modernization  Project 

TPRISM 

Paragraph 

Improve  interoperability 

DMS 

5.3.1 

DVTC 

5.3.2 

Y2K 

5.4.1 

HLA 

5.4.4 

Modernize  infrastructure 

DISN 

5.1.1 

PPC4I 

5.1.2 

Fort  TRADOC 

5.1.3 

ASIMS  FEP 

5.2.1 

PC  based  RJE 

5.2.1 

Incorporate  information 

DISN  Enhanced  IP  Services 

5. 1.1.1 

technology  into  business 

JWICS 

5. 1.1.2 

processes 

SBIS 

5.2.2 

ITP 

5.2.3 

CRXXI 

5.4.3 

ATIMP 

M&S  Modernization 

5.4.4 

5.1  Projects—Networks 

There  are  a  variety  of  on-going  projects  to  modernize  TRADOC's  networks  at  all  levels  of 
integration,  and  to  ensure  mission  applications  have  access  to  network  capabilities  that  support  their 
particular  requirements. 

5.1.1  DISN  Projects 
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The  DISK  is  TRADOC's  primary  WAN.  Its  architecture  was  described  in  paragraph  4.4. 1.2.2. 

DISA  manages  the  pro^am  for  DISN's  modernization,  but  TRADOC  must  plan  for  installations'  access 
and  use  of  DISN.  This  is  a  shared  effort  between  the  installations  and  HQ  TRADOC. 

Since  July  1995  when  the  DISN  strategy  was  announced,  DISA  has  awarded  four  initial  DISN 
contracts,  clustered  by  capabilities  as  follows; 

(1)  DISN  Switched/Bandwidth  Manager  Services-CONUS  (DS/BMS-C).  This  contract,  awarded  to 
MCI  Telecommunications  Corporation,  to  provide  and  manage  transmission  bandwidth  managers  at 
selected  locations  within  CONUS  that  form  the  long-haul  backbone  of  the  DISN  transport  layer.  MCI  is 
responsible  for  DISN  CONUS  implementation  planning  and  support  activities.  Additionally,  the 
DS/BMS-C  contract  will  provide  within  CONUS  the  tandem  circuit  switch  backbone  element  of  the 
Defense  Switched  Network,  the  voice  communications  service. 

(2)  DISN  Transmission  Services-CONUS  (DTS-C).  DISA  awarded  DTS-C  to  AT&T  Federal 
Systems  to  provide  backbone  and  access  area  transmission  services  at  T-1  and  above  bandwidth  rates. 
AT&T  will  provide  wideband  fiber  based  transmission  bandwidth  for  a  DISN  CONUS  SONET 
backbone  and  wideband,  generally  fiber  based,  transmission  bandwidth  connectivity  to  user  locations  at 
approximately  600  DoD  user  locations  in  CONUS.  The  SONET  backbone  will  employ  optical  fiber  and 
provide  information  transport  between  the  DISN  Bandwidth  Managers  acquired  under  the  DS/BMS-C 
contract. 

AT&T  will  provide  information  transport  for  the  aggregate  bandwidth  of  all  Service  Delivety  Points 
in  the  access  area  served  by  each  of  the  Bandwidth  Managers.  To  take  advantage  of  bulk  transmission 
rates,  AT&T  will  bundle  the  access  transmission  into  SONET  for  delivery  to  the  Bandwidth  Managers. 
At  the  customer  access  locations,  transmission  bandwidth  interfaces  at  Tl,  T3  and  SONET  will  be 
provided.  AT&T  will  team  with  Local  Access  Providers  as  required  to  accomplish  the  access  area 
bandwidth  requirements. 

P)  DISN  Video  Services-Global  (DVS-G).  The  DVS-G  contractor,  also  AT&T,  will  provide 
multi-point  dedicated  and  dial-up  video  services,  as  well  as  a  reservation  and  scheduling  system.  As  of 
24  Jul  97,  this  DISN  contract  was  under  negotiation  since  AT&T  is  unable  to  provide  service  in  required 
time  frame.  DISA  is  looking  at  a  60-90  day  delay  for  backbone  support. 

(4)  DISN  Support  Services-Global  (DSS-G).  The  DSS-G  contract,  awarded  to  Boeing  Information 
Services,  provides  integration,  technical,  programmatic,  and  operations  support  for  the  DISN  worldwide. 
The  DSS-G  contract  is  the  vehicle  to  support  DISA's  life-cycle  management  of  the  DISN.  DISA  will 
order  support  services  from  this  contract  on  a  delivery  order  basis  with  specifically  defined  performance 
requirements  and  schedules.  The  Army  may  also  acquire  support  services  under  this  contract  through 
DISA. 

The  CONUS  transition  will  integrate  the  separate  contract  activities  (DS/BMS-C,  DTS-C,  and 
DVS-G)  to  build  the  new  DISN  CONUS  to  which  the  current  DISN  Transition  Contract  services  will 
migrate.  The  transition  is  on-going  and  will  be  completed  during  this  year.  It  includes  three  stages: 
Installation,  Systems  Configuration,  and  Cut-over. 

(1)  Installation  includes  the  installation  of  12  switches,  35  BWMs,  and  establishment  of  the  primary 
and  alternate  DISN  Network  Operations  Centers  (NOCs),  as  well  as  installation  of  initial  backbone  and 
access  transmission  services. 

(2)  Systems  Configuration  is  the  phased-in  configuration  of  network  infi’astructure  elements  and 
establishment  of  overall  network  connectivity  in  preparation  for  the  switched  and  dedicated  service 
cut-over  of  individual  end-user  SDPs.  It  includes  backbone  and  access  paths  between  and  to  BWMs,  and 
bridging  ISTs  that  connect  DISN  CONUS  switches  to  DTC  switches  to  prevent  interruption  of  current 
service  through  the  transition. 

(3)  Cut-over  Stage  is  the  cut-over  of  switched,  dedicated,  and  VTC  services  from  the  DTC  to  DISN. 
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Two  types  of  cut-overs  will  be  completed  in  parallel:  switched  network  services  and  dedicated  services. 
Switched  services  require  the  rehoming  of  end  office  PBXs  and  4-wire  circuits.  Dedicated  services,  to 
include  dedicated  VTC  require  the  cut-over  of  fixed  transmission  facilities.  These  two  service  cut-overs 
will  be  accomplished  based  on  the  site's  geographic  location.  CONUS  has  been  divided  into  nine  areas, 
and  the  cut-overs  are  scheduled  in  nine  sequential  phases  corresponding  to  those  areas.  Video  cut-overs 
will  take  place  as  a  separate,  but  simultaneous  transition,  and  video  facilities  will  be  transitioned  by 
VTC  communities  of  interest.  Cut-over  of  the  local  access  transmission  extension  pipes  will  be  phased 
in  sequentially  with  the  sites  prior  to  the  cut-over  of  the  switched  and  dedicated  services. 

5.1. 1.1  DISN  Enhanced  IP  Services 

piSN  Enhanced  IP  Services  is  DISA's  replacement  for  the  DSI,  as  described  in  paragraph  4.3. 1.3.3. 
Services  are  offered  through  the  DISN,  but  are  designed  specifically  to  support  the  kind  of  traffic 
generated  by  M&S.  The  transition  will  occur  in  FY98.  TRADOC  has  14  DSI  nodes,  all  of  which  are 
committed  subscribers  to  DISN  Enhanced  IP  Services  in  FY98.  Upgrades  in  site  routers,  Improved 
Network  Encryption  System  (INES),  and  VTC  equipment  are  required  to  make  the  transition.  DISA  has 
scheduled  these  upgrades  for  all  TRADOC  sites  prior  to  1Q98. 

The  transition  will  also  include  the  new  fee-for-service  approach.  The  DSI  had  previously  been 
centrally  funded  for  all  subscribers  at  DoD  level.  With  the  transition,  subscribers  must  pay  the  bill.  For 
FY98,  HQ  TRADOC  will  centrally  fund  continued  use  for  TRADOC  subscribers.  A  study  being 
conducted  by  the  TRADOC  Analysis  Center  (TRAC),  in  coordination  with  the  DC  SIM,  will  help 
establish  requirements,  costs  and  alternatives  for  FY99-2005.  The  study  results  will  be  presented  to  the 
TRADOC  M&S  Advisory  Coimcil  in  January  1998. 

5.1.1.2  JWICS 

JWICS  provides  SCI  level  networking  as  described  in  paragraph  4.4. 1 .2.2.  The  TRADOC  DCSINT 
leads  the  effort  to  provide  JWICS  access  to  TRADOC  installations  as  part  of  the  TRADOC  Intelligence 
Network  Architecture  (TINA)  project.  JWICS  nodes  have  been  installed  at  Forts  Huachuca  and  Monroe. 
Installation  of  a  node  at  Fort  Leavenworth  is  scheduled  before  1Q98.  Satellite  sites  at  Knox,  Rucker, 
Leonard  Wood,  Sill,  Bliss  and  White  Sands  Missile  Range  are  scheduled  for  connection  before  1Q98. 
TINA  also  requires  fielding  of  Sun  Ultra  1  Model  140  platforms  with  an  Ultra  SPARC- 1  processor. 
These  platforms  are  scheduled  for  delivery  prior  to  1Q98.  The  Ground  Intelligence  Support  Activity 
(GISA)  is  doing  the  installation,  and  will  schedule  training  during  FY98. 

5.1.2  PPC4I  Projects 

CECOM  manages  PPC4I  Army-wide.  PPC4I  installs  networking  components,  mostly  though  not 
exclusively  CANs,  as  described  in  paragraph  4.4. 1 .4.  PPC4I  has  four  sub-pro^ams,  each  fielding 
separate  components  of  installations'  network  infrastructure:  (1)  telephone  switch;  (2)  the  outside 
transmission  media  cable  plant;  (3)  the  installation's  backbone  data  network;  and  (4)  the  gateway  to 
external  data  networks.  The  four  sub-programs  are  discussed  below. 

•  MACOM  Telephone  Modernization  Program  (MTMP)  provides  TRADOC  installations  with 
telephone  switch  upgrades. 

•  Outside  Cable  Plant  Rehabilitation  (OSCAR)  was  originally  designed  to  upgrade  the  cable  plant 
in  support  of  telephone  systems  upgrades.  The  scope  has  been  expanded  to  include  "dark"  and 
"lit"  fiber  in  support  of  both  telephone  and  data  users. 

•  Common  User  Installation  Transport  Network  (CUITN)  provides  an  installation  backbone  data 
network  to  intercoimect  LANs,  hosts,  and  gateways.  CUITN  installs  a  high  bandwidth  data 
network  with  single-mode  optical  fiber  cable  using  ATM/SONET  technology  switches/routers 
collocated  with  the  telephone  DCO  and  RSUs.  The  CUITN  will  provide: 

=>  the  ADN  and  interconnecting  fiber-optic  cable 
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=>  connectivity  from  the  ADN  to  each  electronic  mail  (E-mail)  host 
=>  cormectivity  from  the  ADN  to  each  DDN  gateway 
=>  cormectivity  from  the  ADN  to  N-ISDN  2B+D  service 

=>  cormectivity  from  the  ADN  to  selected  war  fighter  and  power  projection  critical 
LANs 

•  Army  DISN  Router  Program  (ADRP)  provides  the  components  necessary  for  Army  installations 
to  access  the  NIPRNET. 

5.1. 2.1  Status 

All  TRADOC  installations  have  received  MTMP  switch  replacements  and  all  telephone  systems  are 
NANP  compliant.  Total  OSCAR  contract  expenditures  on  TRADOC  installations  since  FY91  is  $31.4 
million.  One  third  of  these  funds  were  provided  by  TRADOC  installation  users.  The  remainder  was 
provided  by  DA  under  the  OSCAR  national  infrastructure  program.  A  CUITN  upgrade  is  in  progress  at 
Fort  Bliss.  CUITN  has  not  fielded  much  inside  TRADOC  due  to  its  fielding  approach,  explained  in  the 
next  paragraph.  The  initial  ADRP  upgrades  for  TRADOC  installations  are  complete. 

5.1. 2.2  Schedule 

The  schedule  for  PPC4I  is  determined  by  the  installation  sequence  list  (ISL)  (Table  91.  as  ranked  by 
DA  DCSOPS.  Only  fom  TRADOC  installations  (Forts  Bliss,  Berming,  Gordon,  and  Sill)  are  in  the  ISL 
top  20.  The  likelihood  of  other  TRADOC  installations  receiving  PPC4I  funding  for  CUITN  prior  to 
FY99  is  low.  Deepening  TRADOC's  problem  is  the  PM's  approach  to  fielding,  which  has  been  a  total 
solution  to  the  high  ranking  installations,  leaving  lower  installations  without  even  the  most  critical 
improvements.  There  are  no  firm  fielding  dates  associated  with  these  rankings  and  the  pace  is  dependent 
on  continued  Army  funding.  For  purposes  of  gauging,  we  know  PPC4I  has  existed  four  years  and  Ft. 
Bliss,  TRADOC's  highest  ranking  installation,  began  work  during  FY97. 

Table  9.  Installatiou  sequence  list 
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3.  Ft  Stewart 

96 

4.  Ft  Campbell 

96 

5.  Ft  Lewis 

96 

6.  Ft  Bliss 

97 

7.  Ft  Drum 

99 

8.  Ft  Carson 

99 

9.  Schofield  Bks 

00 

10.  Ft  Wainwright 

01 

11.  Ft  Riley 

01 

12.  Ft  Shatter 

02 

13.  Ft  Benning 

14.  Rock  Island  Ars 

02 

15.  Redstone  Ars 

16.  Anniston  Depot 

17.  Ft  Gordon 

03+ 

18.  Fort  McPherson 

19.  Ft  Sill 

20.  Ft  Polk 

03+ 

21.  Ft  Lee 

22.  Ft  Knox 

03+ 

03+ 

23.  Dahlonego  RTA 

24.  Ft  Monmouth 

03+ 

25.  Sunny  Point  Term 

26.  Ft  Irwin  8<NTC 

27.  Ft  Jackson 

03+ 

28.  Ft  Lnrd  Wood 

03+ 

29.  Ft  Sam  Houston 

X.  FtEustis 

03+ 

31.  Yakima  Firing  Qr 

32.  Ft  Detrick 

33.  Yuma  Proving  Grnds 

34.  Ft  Gillem 

35.  Ft  Rucker 

03+ 

36.  Ft  Huachuca 

03+ 

37.  Ft  McNair 

38.  White  Sands  MR 

39.  Ft  Myer 

40.  Ft  Leavenworth 

03+ 

41.  Ft  Meade 

42.  Walter  Reed  AMC 

43.  West  Point  Mil  Res 

44.  Ft  Story 

03+ 

45.  Carlisle  Bks 

03+ 

NOTE:  Funcfing  year  is  "Best 
Guess"  based  on  funded 
program  levels. 


63.  Ft  Monroe 

64.  Ft  Richardson 

65.  Tobyhanna  AD 

66.  Waten/liet  Ars 

67.  Crane  AAA 

68.  Lake  City  AAP 

69.  PresidiofDLI 


03+ 


03+ 


Improving  TRADOC's  individual  installations'  ISL  rankings  is  unlikely.  Instead,  TRADOC  has 
recommended  to  HQDA  that  a  package  of  capabilities  encompassing  all  TRADOC  installations, 
although  well  short  of  full-up  CUITN  upgrades,  be  ranked  as  TRADOC's  highest  "installation"  on  the 
ISL.  ITie  package,  known  as  "Fort  TRADOC",  would  improve  the  command's  CAN  architectures  as 
justified  by  TRADOC's  role  in  architecting  and  training  Force  XXI,  emphasizing  user  locations  for 
distributed  learning  and  M&S.  The  capabilities  and  architecture  were  discussed  in  paraCTaph  4.4. 1 .4. 
The  precise  location  of  upgrades  (i.e.,  buildings)  is  subject  to  change  since  TRADOC's  KEI  funds  are 
also  used  each  year  to  incrementally  implement  the  Fort  TRADOC  approach. 

5.1.3  Fort  TRADOC  (KEI  Package) 
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TRADOC  DCSIM  competes  annually  in  the  CG's  KEI  process  for  funds  to  insert  technology  into 
installations'  IM  infrastructure.  In  KEI96  and  KEI97,  the  emphasis  was  on  CAN  upgrades  to  support 
Classroom  XXI  user  locations.  Other  DCS  also  compete  for  KEI  funds,  which  often  involves 
modernization  that  must  be  synchronized  with  Fort  TRADOC.  Most  notably,  DCST  has  been  successful 
in  funding  inside  the  building  infrastructure  (LANs  and  platforms)  to  support  Classroom  XXI.  Using 
KEI  funds,  TRADOC  has  moved  from  a  fragmented  set  of  CAN  capabilities,  to  a  minimum  architecture 
that  provides  access  to  a  FDDI  backbone  to  high  priority  users  and  a  T-1  WAN  connection  into  the 
backbone.  As  shown  in  Figure  3 1 .  KEI96  funds  were  used  to  install  fiber  to  61  buildings  on  TRADOC 
posts,  and  to  provide  T-1  NIPRNET  connectivity  at  seven  posts.  KEI97  funds  were  used  to  provide  fiber 
connectivity  to  an  additional  44  buildings,  T-1  MPRNET  access  at  seven  additional  posts,  and 
SIPRNET  access  for  nine. 

In  the  KEI  competition  for  FY98,  TRADOC  packaged  into  one  submission  its  highest  priorities  for 
achieving  the  Fort  TRADOC  target  CAN  architecture.  The  KEI  submission  is  a  subset  of  the  "Fort 
TRADOC"  package  TRADOC  has  requested  DCSOPS  rank  as  our  next  CUITN  effort.  This  KEI 
increment  is  potentially  within  TRADOC's  own  means  to  implement,  while  the  CUITN  version  will 
require  external  support.  In  generic  terms,  KEI98  starts  TRADOC's  post-FDDI  CAN  migration  by 
insertinjg  ATM  technology  to  reach  about  36  buildings  with  user  groups  requiring  high  bandwidth 
capabilities.  Figure  32  portrays  the  approach  graphically. 

Beginning  at  Figure  33.  the  KEI  investments  made  at  each  installation  are  depicted  together  with  the 
FY98  Fort  TRADOC  objectives. 

See  also: 

4.4.1 .4  Networks— Installation  Level 


Generic  TRADOC  Installation  Pre-KEI  (95) 


Commaid 

Group 

Cabling  Primarily  Copper 


KEI  96  IM  Improvements 
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KEI  97  IM  Improvements 


Model/Sim  Command 

Group 


Command 

Group  fjgyy  Cablin 


New  Cabling  -  Fiber 


Figure  31.  Prior  Key  Enabling  Investments 


Model/Sim 

6 

AdtfMoiia/ 

BuiUmgt 


Command 

Group 


ATM  KEI 


Figure  32.  KEI98  Generic  Investment  Approach 
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5.1. 3.1  Responsibilities 

DOIMs,  in  close  association  with  functional  users,  define  detailed  requirements  and  manage  local 
arrangements  for  installation  of  networking  components.  DOIMs  are  responsible  for  identifying 
requirements  and  executing  funds  for  inside  the  building  acquisitions,  in  coordination  with  installation 
and  HQ  TRADOC  staff  functional  proponents.  The  DCSIM,  FSSD  is  responsible  for  overseeing  the 
execution  of  the  KEI  funds  associated  with  common  user  network  upgrades. 

5.1. 3.2  Status 

The  FY98  Fort  TRADOC  package  was  validated  for  funding  by  the  KEI  SPRAC.  The  available 
funds  are  not  sufficient  to  implement  all  the  requirements.  Regardless  of  how  far  KEI  funds  stretch  in 
satisfying  these  approved  requirements,  they  remain  high  priorities  for  modernizing  installations'  CANs. 
Therefore,  the  full  package  is  displayed  in  the  series  of  figures  below. 

5.1.3.3  Schedule 

KEI  prioritization  is  an  annual  resource  competition.  Requirements  are  collected  during  the  summer 
months  fi'om  installations  and  worked  by  the  HQ  staff  in  time  for  the  new  fiscal  year.  Individual  projects 
are  executed  by  installations  in  accordance  with  their  own  time  requirements. 

Figure  33.  KEI-- Aberdeen  Provinu  Grounds 

Figure  34.  KEI--Fort  Benning 

Figure  35.  KEI--Fort  Bliss 

Figure  36.  KEI--Carlisle  Barracks 

Figure  37.  KEI-Fort  Eustis 

Figure  38.  KEI-Fort  Gordon 

Figure  39.  KEI—Fort  Hnachuca 

Figure  40.  KEI— Fort  Jackson 

Figure  41.  KEI—Fort  Knox 

Figure  42.  KEI--Fort  Leavenworth 

Figure  43.  KEI--Fort  Lee 

Figure  44.  KEI--Fort  Leonard  Wood 

Figure  45.  KEI--Fort  Monroe 

Figure  46.  KEI--Redstone  Arsenal 

Figure  47.  KEI--Fort  Rucker 

Figure  48.  KEI  -Fort  Sill 

Figure  49.  KEI--White  Sands  Missile  Range 

Figure  50.  KEI--Presidio  of  Monterey 

5.2  Projects— Platforms 

With  increased  use  of  client  server  software  architecture  and  connectivity  of  LANs,  platform 
architecture  is  shifting  from  installation  level  platforms  to  mission,  local  and  personal  level  platforms.  It 
is  common  that  Army  and  DoD  PM's  field  platforms  sized  as  servers  for  their  mission  applications,  e.g., 
ITP,  SBIS  and  DMS,  which  are  combining  to  reduce  dependency  on  installation  level  mainframes.  PM's 
assume  platforms  at  the  personal  level,  or  the  client  portion  of  the  overall  system,  are  already  there  or 
will  be  provided  by  the  installation.  TRADOC  must  continue  to  upgrade  its  personal  computer  base,  but 
there  is  no  formal  project  to  do  so. 

5.2.1  IBM  mainframe  replacement 

IBM  mainframes  purchased  in  1985  and  currently  used  at  14  TRADOC  installations,  will  not  run 
after  CY  1999.  In  the  baseline  system  architecture,  these  mainframes  run  several  applications: 
Professional  Office  Systems  (PROFS)  e-mail,  TRADOC  ISMs,  and  installation  xmique  applications. 
They  also  provide  the  front  end  processor  (FEP)  and  remote  job  entry  (RJE)  components  required  to 
communicate  with  ASIMS  running  at  the  DMCs. 
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On  10  Dec  96,  HQ  TRADOC  Chief  of  Staff  approved  a  mainframe  Table  10.  Fielding  schedule  for 
replacement  strategy  in  which  the  DCSIM  will  field  replacements  ASIMS  FEP 

for  the  ASIMS  FEP  and  RJE  components.  The  applications  that  run 
on  the  mainfi’ame  will  be  replaced  by  other  decentralized  efforts: 

=>  PROFS  e-mail  system  will  be  replaced  by  the  DMS  program 
and  installations'  acquisition  of  client  server  e-mail  systems 
consistent  with  the  DMS  architecture. 


=>  TRADOC  ISMs  will  be  mostly  replaced  by  DA  fielded 
applications,  such  as  SBIS  and  ITP  modules  and  Standard 
Installation  Division  Personnel  System  3  (SIDPERS3). 


=>  Installation  unique  applications  will  be  migrated  in  various 
ways  to  other  applications  and  platforms.  These  migration  efforts 
are  tied  up  with  questions  of  Y2K  readiness  as  well  as  mainframe 
replacement. 

DCSIM  arranged  for  Information  Systems  Engineering 
Command  (ISEC)  to  perform  FEP  and  RJE  site  surveys  and  to 
install  the  necessary  components.  ISEC  conducted  the  site  surveys 
firom  Dec  96  to  Jul  97.  The  components  necessary  for  PC  based 
RJE  were  fielded  during  FY97.  The  schedule  for  fielding  FEP 
components  is  shown  in  Table  10.  1997  dates  prior  to  this 
publication  have  been  met. 


See  also: 

4.4.2.3  Platforms— Installation  Level 


5.2.2  SBIS 


The  SBIS  program  aims  to  provide  both  a  standard  platform  and  standard  applications  for 
installation  management.  The  program  has  undergone  several  changes  in  scope  since  its  initiation  and 
finally  was  identified  for  termination  in  the  POM  98-03.  The  PEO  Table  11.  Fielding  schedule  for 
STAMIS  will  field  SBIS  servers  and  applications  to  Power  SBIS 

Projection  Platform  (PPP),  Power  Support  Platform  (PSP)  sites  and 


TRADOC 

Post 

Start 

Date 

Finish 

Date 

BEN 

1/5/98 

2/5/98 

BLI 

10/20/97 

11/20/97 

CAR 

8/25/97 

9/5/97 

EUS 

4/6/98 

4/30/98 

GOR 

11/17/97 

12/17/97 

HUA 

2/9/98 

3/31/98 

JAC 

6/29/98 

7/30/98 

KNO 

7/14/97 

7/30/97 

LEA 

8/24/98 

9/30/98 

LEE 

3/9/98 

4/9/98 

LWD 

5/4/98 

6/4/98 

McC 

8/25/97 

9/5/97 

POM 

8/11/97 

8/16/97 

RUC 

6/11/97 

6/24/97 

SIL 

6/1/98 

7/1/98 
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Projection  Platform  (PPP),  Power  Support  Platform  (PSP)  sites  and 
Fort  Leavenworth  before  the  pro^am  terminates  after  FY  98.  The 
fielding  schedule  for  TRADOC  sites  follows. 


See  also: 

4A.2.2  Platforms— Mission  Level 
Appendix  C:  Mission  Applications— SBIS 

5.2.3  ITP 

The  ITP  program  was  initiated  to  field  target  architecture 
platforms  and  applications  imtil  SBIS  provided  an  open,  distributed 
architecture.  Although  the  software  engineering  effort  was  scaled 
back,  the  PM  SBA  did  field  ITP  platforms  and  available  modules 
during  FY97.  The  program  terminates  after  FY98. 

See  also: 

4.4.2.2  Platforms— Mission  Level 

Appendix  C:  Mission  Applications— Installation  Transition 
Processing  (ITPI 

5.3  Projects—Support  Applications 

There  are  two  projects  to  modernize  support  applications  of 
fundamental  interest  to  TRADOC:  DMS  and  DVTC. 

Improvements  to  other  tools  for  command  wide  coordination  are 
likely  to  mature  soon,  but  are  not  identifiable  projects  at  this  point. 

5.3.1  Defense  Messaging  System  (DMS) 

DMS  is  a  DoD  managed  program  to  establish  a  joint  messaging  capability  consistent  with  the  joint 
concept,  C4Ifor  the  Warrior.  The  DoD  ASD(C3I)  stated  in  a  memo,  SUBJECT:  Electronic  Messaging 
Policy  -  Implementation  Guidance,  9  March  1995,  to  all  services,  "There  will  be  one,  seamless, 
end-to-end  global  electronic  messaging  service  within  the  Department  of  Defense...  All  electronic 
messaging  (AUTODIN  and  legacy  electronic  mail)  within  the  Department  of  Defense  must  migrate  to 
DMS-compliant  messaging  as  rapidly  as  possible."  The  memo  placed  a  moratorium  on  the  acquisition  of 
non-compliant  messaging  systems.  ODISC4  reinforced  this  with  their  message  (SAIS-PP,  191615Z 
DEC  95,  Subject:  Reconfiguration  of  The  Army  Defense  Message  System  (DMS)  Management 
Structure). 

See  also: 

4.4.3. 1  E-mail 


TRADOC 

Post 

Start 

Date 

Finish 

Date 

APG 

8/5/97 

1/19/98 

BEN 

6/24/97 

11/3/97 

BLI 

5/28/97 

10/3/97 

EUS 

7/5/96 

12/5/97 

GOR 

7/5/96 

HUA 

7/22/97 

12/5/97 

JAC 

5/27/97 

12/5/97 

KNO 

7/8/97 

12/5/97 

LEA 

7/22/97 

1/6/98 

LEE 

7/8/97 

LWD 

7/9/97 

12/5/97 

MON 

11/10/97 

12/5/97 

RUC 

8/5/97 

12/5/97 

SIL 

6/24/97 

9/19/97 

For  more  information: 

http://www-tradoc.monroe.armv.mil/dcsim/dms/dms.htm 

5.3.1.1  Responsibilities 

DMS  is  a  DoD  managed  program,  but  responsibilities  are  distributed.  DoD  is  mostly  concerned 
with  designing  the  program  and  fielding  the  infrastructure  components,  e.g.,  the  message  transfer  agents 
and  directory  service  agents.  Army  has  a  Project  Management  Office  (PMO),  and  is  assisted  by  CECOM 
and  others,  to  include  DOIMs  for  DMS  components  that  neither  the  DoD  nor  DMS-Army  provide. 

The  DMS  program  assumes  the  availability  of  suitable  CAN  and  LANs  and  client  PCs.  DISA  will 
not  fund  acquisitions  of,  or  upgrades  to,  CANs  or  LANs,  which  are  instead  identified  as  a 
Service/ Agency  responsibility.  The  DMS-Army  will  provide  a  suite  of  interconnected  DMS  server 
hardware  and  software  adequate  for  organizational  messaging,  i.e.,  the  AUTODIN  replacement 
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architecture. 

The  Army  PMO  is  the  focal  point  for  acquiring  DMS  components.  Customers  identify 
requirements  and  MIPR  funds  to  PMO.  TRADOC  has  a  command-wide  offload  Waiver  approving  use 
of  the  DMS  contract.  The  PMO  will  also  provide  guidance  on  acceptable  messaging  and  directory 
components  and  security  requirements.  DOIMs  will  prepare  any  requests  for  DMS  waivers  in  TRADOC 
and  submit  them  in  writing  to  DCSIM  for  further  processing.  The  Army  PMO  DMS  evaluates  waivers 
and  makes  an  approval  recommendation  to  ODISC4.  Waivers  ultimately  must  be  approved  by  DISA. 

5.3.1.2  Schedule 


100% 
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Figure  51.  Phased  migration  to  DMS  for  individual  users 


DISA  will  turn  off  AUTODIN  by  2000,  so  the  fielding  schedule  for  organizational  messaging 
components  must  be  completed  prior  to  then.  However,  given  TRADOC's  responsibilities  and  lack  of 
funds  for  acquiring  DMS  components  for  individual  users,  TRADOC  must  delay  implementing  DMS 
across  the  command  until  beginning  in  2005.  Meanwhile,  Table  12.  Fielding  schedule  for 

TRADOC  will  invest,  through  normal  life  cycle  replacement,  in  DMS  organizational  users 

personal  level  platforms  that  can  support  the  DMS  architecture. 
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personal  level  platforms  that  can  support  the  DMS  architectme. 
This  approach  is  illustrated  in  Figure  51.  Table  12  provides  the 
PM's  fielding  schedule  for  unclassified  organizational  DMS 
components. 


5.3.2  Desktop  VTC 


HQ  TRADOC  directed  DVTC  efforts  are  moving  out  of  the 
fielding  phase  and  into  operations.  Future  extensions  of  capabilities 
will  be  achieved  through  local  or  proponent  staff  investments.  HQ 
TRADOC  will  upgrade  the  fielded  DVTCs  to  increase  switching 
capabilities  in  the  multipoint  control  unit  to  include  16  users  (i.e., 
coverage  for  all  TRADOC  installations)  in  one  session  and  to 
increase  switching  capacity  (M60  switch)  at  local  level  for 
remaining  installations  with  a  requirement,  i.e.,  Ft.  Leonard  Wood 
and  Ft.  Gordon.  As  resources  and  requirements  dictate,  HQ 
TRADOC  will  consider  other  upgrades,  e.g.,  multi-point 
application  sharing  (vice  one  to  one  application  sharing  that  is 
currently  available),  and  displays  with  continuous  presence 
("Hollywood  Squares"). 

5.4  Projects—Mission  Applications 


As  a  general  rule,  fimctional  proponents,  not  DCSIM,  lead 
projects  to  modernize  mission  applications.  DCSIM  is  the  lead  for 
TRADOC's  Y2K  approach,  which  affects  all  mission  area 
applications.  Consistent  with  the  categories  used  throughout 
TPRISM,  this  chapter  considers  key  projects  for  training 
applications  (Army  Training  Information  Management  Pro^am 
(ATIMP)  and  Classroom  x5Q),  M&S  applications  (synthetic 
enviromnent  program)  and  installation  management  applications 
(Army  STAMIS,  TRADOC  ISM  and  installation  unique 
application  migration). 

5.4.1  Y2K 

The  change  of  the  century  affects  all  IS  components.  Since 
most  of  the  effort  is  spent  on  the  migration  of  application  software, 

TRADOC's  Y2K  project  is  described  here.  The  Y2K  challenge  is  to 
replace  code  written  to  use  two  digits  in  fields  describing  the  year,  and  to  ensure  that  all  consequences 
(interfaces,  databases,  calls  to  subroutines,  report  formats,  etc.)  are  managed  without  operational  failure. 
In  some  cases,  the  code  is  not  application  software,  but  operating  systems,  meaning  entire  platforms  may 
no  longer  be  serviceable  after  2000,  which  in  turn  has  consequences  for  the  mission  applications  that 
depend  on  such  platforms. 

Although  the  entire  DoD  and  Army  faces  the  Y2K  challenge,  renovations  are  not  centrally  fimded. 
TRADOC  has  therefore  issued  guidance  that  all  TRADOC  activities  that  produce,  maintain,  or  operate 
automated  systems  must: 

=>  Eliminate  or  identify  for  Y2K  retirement  all  automated  systems  that  do  not  truly  assist  in  mission 
accomplishment. 

=>  Spend  no  resources  on  systems  that  will  not  be  in  use  past  1  January  2000. 

=>  Postpone  all  automated  system  enhancements  and  non-essential  sustainment  requirements  until 
they  have  fixed,  tested  and  certified  that  critical  systems  are  Y2K  complaint.  All  Y2K  work  must  be 
accomplished  with  existing  resources;  there  are  no  special  Y2K  funds  programmed. 


TRADOC 

Post 

start 

Date* 

Finish 

Date* 

BEN 

1/17/97 

3/20/98 

BLI 

3/31/97 

10/8/97 

CAR 

5/1/98 

12/2/98 

EUS 

2/24/97 

12/16/97 

GOR 

10/9/96 

8/19/97 

JAC 

12/1/97 

8/13/98 

KNO 

11/3/97 

9/15/98 

LEA 

3/2/98 

10/2/98 

LEE 

10/2/97 

7/10/98 

LWD 

1/5/98 

11/16/98 

MCC 

7/5/96 

7/5/96 

MON 

1/17/97 

12/16/97 

POM 

10/1/98 

5/3/99 

SIL 

10/2/97 

5/22/98 

RUC 

2/2/98 

9/16/98 

*  Typical  tasks  during  this  extended 
period  include: 

•  Site  Survey 

•  Acquisition  Cycle 

•  Contractor  Delivery 

•  System  Integration 

•  Site  Training 

•  Site  Testing 

•  Acceptance 
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For  more  information: 
http://www-tradoc.annv.niil/dcsim/v2k/ 

5.4.1. 1  Responsibilities 

DCSIM  is  the  overall  lead  on  TRADOC's  Y2K  efforts.  DCSIM  operates  TRADOC  Project  Change 
of  Century  WWW  site  to  ensure  awareness  and  coordinate  the  command's  actions. 

Each  functional  proponent  (FP)  and  installation  develops  and  executes  a  risk-based  action  plan  to 
determine  the  scope  of  the  change  of  century  problem.  FPs  and  installations  assess  all  systems  in  their 
inventories  to  ensure  no  mission  critical  system  failures.  They  must  take  the  steps  to  manage  the 
assessment  and  resolution  processes  with  an  acceptable  level  of  risk.  FPs  and  installations  must  maintain 
updated  systems  inventories  to  ensure  all  computer  based  systems  are  accounted  for.  They  should 
conduct  an  impact  assessment  for  all  systems,  followed  by  a  prioritization  for  renovation.  They  must 
develop  timelines  and  select  pilot  projects  to  validate  approach  and  resource  estimates.  They  define 
resource  requirements  for  necessary  resolution  actions  and  implement  solutions. 

5.4.1.2  Schedule 

TRADOC  conducted  an  assessment  of  the  problem  and  operational  risk  during  1997.  That 
assessment  is  nearly  completed.  It  produced  an  inventory  of  mission  essential  TRADOC  systems  and 
installation  systems  that  pass  data  to  DoD,  DA  or  TRADOC  systems  which  will  be  operational  after  3 1 
December  1999.  The  inventory  was  recorded  in  a  TRADOC  DCSIM  Y2K  database  available  on  the 
WWW.  Systems  were  assessed  in  terms  of  Y2K  compliance  and  mission  criticality  and  functional 
proponents  identified  systems  to  be  replaced,  redeveloped  or  retired. 

Currently,  several  phases  are  running  concurrently  to  ensure  systems  targeted  for  retention  are 
operable  after  1999,  and  that  the  migration  path  is  executed  for  systems  that  will  not  be  retained.  During 
renovation,  with  a  completion  target  of  15  Sep  98,  required  system  fixes  will  be  completed.  During 
validation,  with  a  completion  target  of  15  Dec  98,  systems  will  be  confirmed  as  Y2K  compliant  through 
testing  and  certification  processes.  During  implementation,  to  be  completed  by  15  Dec  98,  systems  will 
be  certified  as  fully  integrated  and  operational  after  certification;  and  a  contingency  strategy  will  be 
implemented  for  mission  critical  systems  that  can  not  be  renovated.  Table  13  shows  that  dining 
assessment,  55  of  109  systems  were  targeted  for  retirement.  The  current  phase  of  other  systems  is  also 
shown. 


Table  13.  Y2K  phases 


#  Systems 

Assess 

Renovate 

Validate 

Retire 

MACOM 

38 

2 

2 

9 

25 

Installations 

71 

16 

20 

5 

30 

Total 

18 

22 

14 

55 

5.4.2  ATIMP 

The  ATIMP  provides  Army-wide  oversight  to  the  development,  integration,  and  operations  of  over 
30  training  IS  that  support  institutional  training,  unit  training,  and  training  support.  It  provides  a 
management  and  support  infrastructure  to  integrate  training  IS,  processes,  and  data  integration  and  to 
preclude  the  development  of  unnecessary  or  redundant  training  processes  and  information  systems. 
ATIMP  coordinates  change  management  to  ensure  all  related  requirements  are  considered  prior  to 
implementing  changes  in  training  IS.  ATSC  is  the  executive  agent  for  overseeing  ATIMP. 

ATIMP  has  developed  an  objective  architecture  that  plots  the  migration  and  integration  of  Army 
training  IS  through  FY02.  The  architecture  shows  the  migration  from  current  training  systems  (see 
Appendix  Cl  to  the  systems  shown  in  Figure  28. 
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See  also: 

4.4.4. 1  Training  Applications 


For  more  information: 
http://www.atimt). armv.mil/index.htm 

5.4.3  Classroom  XXI 

This  project  upgrades  training  facilities  and  equipment,  to  include  supporting  networks,  to  bring  the 
training  institution  into  line  with  emerging  training  concepts.  In  TRADOC,  it  upgrades  institutional 
classrooms  and  fields  DTACs. 

See  also: 

4.4.4. 1  Training  Applications 
For  more  information: 

httD://www-dcst.monroe.armv.mil/crxxi/toc.htm 

5.4.3.1  Responsibilities 

DCST  is  the  TRADOC  lead  for  Classroom  XXI,  as  well  as  the  umbrella  Army  Training  XXI 
program,  and  associated  enabling  programs  such  as  Army  Distance  Learning  Plan  and  WARNET. 

DCST  will  assist  schools  with  requirements  determination,  monitoring  schools'  planning  for  command 
wide  consistency,  programming  requirements,  and  developing  an  equipment  procurement  list  to  support 
implementation,  which  they  will  provide  to  Classroom  XXI  developers  via  the  WWW.  DCSIM  assists 
with  integrating  common  user  network  capabilities  with  Classroom  XXI  requirements,  and  otherwise 
assisting  DCST  with  information  technology  issues.  Installations  and  schools  develop  their  own  action 
plans  in  accordance  with  DCST  guidance.  ISEC  is  providing  technical  assistance. 

5.4.3.2  Schedule 

In  the  near  term,  TRADOC  is  modernizing  its  CAN  segments  for  clusters  of  training  buildings  on 
TRADOC  installations  to  increase  readiness  for  classroom  XXI  operations.  As  ADLP  funds  become 
available  for  use  on  TRADOC  installations,  pilot  classrooms  and  DTACs  will  be  fielded  as  shown  m 
Table  14.  Typical  site  preparation  tasks  include:  collect  pre-site  survey  infoimation,  conduct  pre-bnef  to 
installation,  and  conduct  site  survey.  Typical  implementation  tasks  include:  install  equipment,  perform 
facilities  work,  conduct  tests,  and  gain  user  acceptance. 

Table  14.  Fielding  schedule  for  Classroom  XXI 
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Task 

Site 

Start  Date 

Finish  Date 

CRXXI  Site  Preparation 

APG 

4/17/97 

8/28/97 

CRXXI  Implementation 

APG 

2/27/98 

8/21/98 

CRXXI  Site  Preparation 

BEN 

4/17/97 

7/31/97 

CRXXI  Implementation 

BEN 

2/27/98 

8/21/98 

CRXXI  Site  Preparation 

BLI 

4/17/97 

7/31/97 

CRXXI  Implementation 

BLI 

2/27/98 

8/21/98 

CRXXI  Site  Preparation 

CAR 

7/5/96 

7/5/96 

CRXXI  Implementation 

CAR 

7/5/96 

7/5/96 

CRXXI  Site  Preparation 

EUS 

4/17/97 

7/10/97 

CRXXI  Implementation 

EUS 

12/17/97 

6/24/98 

CRXXI  Site  Preparation 

GOR 

4/17/97 

8/7/97 

CRXXI  Implementation 

GOR 

2/27/98 

8/21/98 

CRXXI  Site  Preparation 

HUA 

4/17/97 

8/7/97 

CRXXI  Implementation 

HUA 

2/27/98 

8/21/98 

CRXXI  Site  Preparation 

JAC 

4/17/97 

8/14/97 

CRXXI  Implementation 

JAC 

2/27/98 

8/21/98 

CRXXI  Site  Preparation 

KNO 

4/17/97 

7/24/97 

CRXXI  Implementation 

KNO 

2/27/98 

8/21/98 

CRXXI  Site  Preparation 

LEA 

4/17/97 

9/4/97 

CRXXI  Implementation 

LEA 

2/27/98 

8/21/98 

CRXXI  Site  Preparation 

LEE 

4/17/97 

7/10/97 

CRXXI  Implementation 

LEE 

9/1/97 

6/9/98 

CRXXI  Site  Preparation 

LWD 

4/17/97 

8/28/97 

CRXXI  Implementation 

LWD 

2/27/98 

8/21/98 

CRXXI  Site  Preparation 

POM 

4/17/97 

7/31/97 

CRXXI  Implementation 

POM 

2/27/98 

8/21/98 

CRXXI  Site  Preparation 

RED 

7/5/96 

7/5/96 

CRXXI  Implementation 

RED 

7/5/96 

7/5/96 

CRXXI  Site  Preparation 

RUC 

4/17/97 

8/28/97 

CRXXI  Implementation 

RUC 

12/17/97 

6/24/98 

CRXXI  Site  Preparation 

SIL 

4/17/97 

7/24/97 

CRXXI  Implementation 

SIL 

2/27/98 

8/21/98 

5.4.4  M&S  Modernization 

The  Army's  effort  to  mature  M&S  applications  into  an  intonated  synthetic  environment 
architecture  includes  several  programs  aimed  at  achieving  the  objective  architecture  described  in 
paragraph  4.4.4.2.  The  migration  to  HLA,  CATT,  WARSIM2000,  and  JWARS  are  addressed  in  the 
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sub-paragraphs  below.  Another  project,  the  Battle  Lab  Reconfigurable  Simulator  Initiative  (BLRSI),  was 
recently  terminated  due  to  funding  cuts.  DCSCD  is  currently  establishing  a  plan  to  meet  requirements 
for  a  Battle  Lab  research  tool.  Combat  developers  will  prepare  and  coordinate  the  performance 
specifications,  and  in  coordination  with  STRICOM  will  develop  an  Operational  Requirements 
Document  (ORD).  STRICOM  will  maintain  available  reconfigurable  simulator  funding  in  FY  97  and 
FY  98  to  meet  this  requirement. 

The  migration  to  HI. A  is  mandated  by  DoD.  TRADOC  is  committed  to  support  it.  The  DoD 
Modeling  and  Simulation  Master  Plan  required  a  "review  [of]  all  ongoing  DoD  M&S  projects  and/or 
programs  by  second  quarter  FY  1997  for  feasibility  of  immediately  adopting  the  HLA.  If  not 
immediately  feasible,  these  reviews  shall  establish  the  date  by  which  each  program  shall  comply.  If  a 
specific  M&S  project  and/or  program  is  unable  to  comply  with  the  HLA,  the  developing  Component 
must  report  the  reason(s)  for  non-compliance  to  the  DDR&E."  The  initial  report  was  sent  to  DMSO  30 
Jun  97.  The  costs  for  modifying  simulations  for  HLA  compliance  must  come  from  the  proponent  for  the 
simulation,  which,  for  TRADOC  is  estimated  to  be  in  the  millions  of  dollars  over  the  next  five  year 
period.  Development  programs  that  cannot  show  an  HLA  migration  plan  cannot  be  continued.  After  1 
Oct  2000,  non-compliant  systems  can  no  longer  play  in  M&S  confederations. 


10  Sept  96  31  Mar  - 16  Mv  97 


30  Jun  97 


1  Oct  00 


Inventory 

Simulations 

Identify  as: 
-Compliant 

immediately 

-Compliant 

later 

-Retire 


-Integrate 
domains  and 
identify 
opportunities 

-Approve  HLA 
requirements 

-Outcome  - 
approved  list 
of  simulations 
by  domain 


Cease 

Development 
or  Modification 


Figure  52.  Schedule  for  Migration  to  HLA 


The  schedule  for  CATT,  WARSIM,  OneSAF  and  related  M&S  modernization  projects  is  depicted 
in  Figure  53.  WARSIM2000  initial  operation  capability  (IOC)  is  in  FY99.  Fielding  to  TRADOC  is 
scheduled  to  begin  in  FY03.  IOC  for  CCTT  is  also  FY99,  with  fielding  to  Forts  Knox  ^d  Benning 
planned  for  that  same  year.  The  Symthetic  Theater  of  War- Architecture  (STOW-A)  project  shovm  below 
is  a  suite  of  equipment  to  support  links  among  live,  virtual,  and  constructive  M&S.  STOW-A  will 
provide  an  interim  training  capability,  and  its  lessons  learned  will  be  used  to  help  develop  CCTT  and 
WARSIM  applications. 
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1996 


1998 


2000 


ALSP  CanfMeraition- 


CBS 
CSS 


FOC 


VWRSIM 


IOC 


SIIWET.  - 
AIRNET 

OCTTSAF^ 
NbdSAF  — 
DARPAOpenSAF. 


ONE  SAF* 


Janus 
JCM  ~ 
JTS  - 


Figure  53.  Modernization  Schedule  for  TEMO  M&S  Applications 


In  November  1995,  the  JWARS  Office  was  established  to  develop  JWARS  The  JW^S  Office  is 
under  direction  of  the  Director,  Program  Analysis  and  Evaluation  (DPA&E)  within  OSD.  JW^S  will 
replace  several  ACR  domain  applications  described  in  paragraph  4.3.4.2.  The  schedule  is  depicted  m 
Figure  54.  JWARS  will  be  HLA  compliant.  It  will  be  developed  incrementally  m  blocks,  corresponding 
to  prioritized  functional  requirements.  JWARS  development  is  in  the  prototype  stage.  A 
proof-of-concept  testbed  has  been  designed  and  is  being  implemented. 


Figure  54.  Modernization  Schedule  for  ACR  M&S  Applications 


See  also: 

5. 1.1.1  DISN  Enhanced  IP  Services 

5.4.5  Installation  Management  Applications 

TRADOC  uses  installation  management  applications  froni  a  variety  of  sources,  most  from 
programs  managed  external  to  TRADOC.  TRADOC  must  participate  during  development,  site  surveys 
and  fielding  to  ensure  the  applications  can  be  inserted  into  a  prepared  infrastructure. 
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5.4.5.1  Installation  Support  Modules 

As  described  in  the  baseline  system  architecture  (see  paragraph  4.3 .4.3),  there  are  two  sets  of  ISMs: 
one  fielded  by  TRADOC,  and  another  set  being  built  and  fielded  by  DA  in  their  ITP  and  SBIS 
programs.  TRADOC  will  not  run  overlapping  applications.  Therefore,  effort  expelled  on  TRADOC 
ISMs  is  mostly  aimed  at  migrating  away  from  them  and  toward  Army  ISMs  and  STAMIS,  not  all  or 
which  are  available  yet. 

5.4.5.1.1  Responsibilities 

The  DOIM  at  Fort  Sill  developed  most  TRADOC  ISMs  and  continues  to  be  responsible  for  their 
maintenance  and  migration.  DOIMs  at  each  installation  run  the  ISMs  in  their  data  processing  installation 
(DPI).  HQ  TRADOC  staff  proponents,  primarily  the  DCSBOS,  define  the  operational  reqmrements  and 

priorities. 

The  PM  for  Sustaining  Base  Automation  is  developing  the  Army's  ISMs  for  ITP  and  SBK,  with 
primary  software  engineering  support  from  the  Software  Development  Center  in  Washington  DC. 
DISC4  is  the  Army  staff  integrator.  HQDA  functional  proponents  define  the  individual  modul^ 
requirements.  DA  has  been  responsible  for  fielding  both  the  hardware  environment  and  the  software 
applications  to  installations. 

5.4.5.1.2  Schedule 

The  schedule  for  migrating  away  from  TRADOC's  ISMs  is  tied  up  with  the  Y2K  challenge,  the 
IBM  mainframe  replacement  project,  and  the  availability  of  Army  replacement  applications.  See  the 
Y2K  and  Fielding  Timeline  pages  on  the  DCSIM's  homepage  for  information  on  the  migration  planmng 
for  specific  applications.  The  SBIS  and  ITP  ISMs  have  been,  or  will  be  fielded,  with  few  exceptions, 
coincident  with  the  insertion  of  the  platforms. 


For  more  information: 

httn  ://www-tradoc .  armv.mil/netvizy  svncmatrix/index.html 


5.4.5.2  Civilian  Personnel  Regionalization 


The  reorganization  of  civilian  personnel  services  requires  the  introduction  of  a  new  IS,  referred  to  as 
the  modem  system.  In  1995,  the  Deputy  Assistant  Secretary  of  Defense  for  Civilian  Personnel  Policy 
[DASD(CPP)]  established  the  Reg/Mod  Division  within  the  Civilian  Personnel  Managenient  Service 
(CPMS).  The  Division's  charter  is  to  oversee  and  integrate  program  activities  and  to  provide  mnctional 
guidance  and  direction  for  developing  the  modem  system.  The  acquisition,  development,  configuration, 
integration,  implementation,  and  life-cycle  management  of  the  modem  system  was  brou^t  imder  the 
Major  Automated  Information  system  Review  Council  (MAISRC)  process.  The  Central  I^sign  Achvity 
(CD A)  at  the  Headquarters  Air  Force  Personnel  Center  AFPC),  Randolph  Air  Force  Base  (AFB), 
TX,  was  designated  as  the  software  development  activity  for  the  modem  system. 


During  FY97  a  substantial  effort  has  been  made  to  ensure  development,  testing,  and  training 
activities  were  put  in  place  to  meet  the  goal  to  begin  fielding  the  modem  system  in  FY98.  DoD  wil 
begin  developing  training  materials  or  identify  courses  associated  with  the  development, 
implementation,  and  functional  use  of  the  modem  systern.  System  and  application  testing  will  occur.  A 
DoD-wide  implementation  and  transition  plan  will  be  built  to  ensure  a  smooth  transition  from  the  legacy 
to  the  modem  system.  Upgrade  and  acquisition  of  hardware  and  software  will  continue  in  support  of 
modernization.  A  central  network  database  management  system  will  be  put  in  place  to  reduce  workload 
on  the  Components.  The  system  will  be  fielded  after  system  testing  and  operator  traimng  efforts  are 
completed. 


5.4.5.3  MWRMIS 

The  Community  and  Family  Support  Center  (CFSC),  an  HQDA  field  operating  activity  manages  the 
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development  and  fielding  of  MWRMIS.  CFSC  secures  an  MOI/MOU  with  gaining  installations' 
Directors  of  Community  Activities  prior  to  fielding.  MWRMIS  applications  are  fielded  as  the  are 
available.  The  next  module  scheduled  for  fielding  is  RECTRAC. 

Table  15.  RECTRAC  Fielding  Schedule _ 


Site 

Team  arrives 

Training 

Live  Production 

Ft  Leavenworth 

28  Sep  97 

6  Oct  -  7  Nov  97 

7  Nov  97 

Ft  Eustis/Story 

6  Oct  97 

13  Oct  -  21  Nov 

21  Nov 

Ft  Monroe 

3  Nov  97 

10  Nov -9  Jan  98 

9  Jan  98 

Ft  Beiming 

5  Jan  98 

12  Jan  -  13  Mar  98 

13  Mar  98 

Ft  Lee 

26  Jan  98 

2  Feb  - 13  Mar  98 

13  Mar  98 

Ft  Rucker 

2  Mar  98 

9  Mar  -  27  Mar 

27  Mar  98 

Presidio  Monterey 

29  Jun  98 

6  Jul  -  24  Jul  98 

24  Jul  98 

5.5  Modernization  Resources 

TRADOC  IS  modernization  requires  both  OPA2  and  OMA  funds.  Most  of  the  funds  required  to 
implement  the  objective  system  architecture  are  managed  outside  TRADOC  in  DoD  and  Army  projects 
such  as  DISN,  PPC4I,  DMS,  SBIS,  and  STAMIS.  TRADOC  manages  the  funding  for  the  Army's 
ADLP,  which  includes  TRADOC's  Classroom  XXI  project,  but  also  includes  Army-wide  modernization 
of  training  equipment.  TRADOC  is  also  budgeted  OPA2,  earmarked  for  the  IMA,  and  OMA  which  is 
often  used  for  IMA  modernization  requirements  short  of  OPA  thresholds. 

OPA2  supports  IMA  investment  costs  over  $100K.  Planning  for  OPA2  requirements  is  done  via 
TRADOC's  submissions  to  the  Army  RDA  Plan  and  associated  input  to  the  POM  to  cover  OMA  tails, 
i.e.,  operational  expenditures  that  are  consequences  of  the  planned  OPA2  investments.  Begirming  in 
1997,  DCSRM,  rather  than  DCSIM,  manages  the  command's  OPA2.  The  major  part  of  TRADOC's 
OPA2  account  is  now  used  for  an  Army  project  (ADLP)  rather  than  internal  TRADOC  investments. 
HQDA  prepares  the  Army  RDA  Plan  and  periodically  requests  input  from  the  MACOMs.  The  Army 
^A  Plan  primarily  contains  OPA  requirements,  but  also  reflects  the  OMA  required  to  execute  the  OPA 
investment  dollars.  Depending  on  timelines  for  the  submissions  to  HQDA,  DCSIM  solicits  OPA2  UFRs 
from  the  installations  and  HQ  elements.  Architecture  framework  documents  submitted  by  the 
installations  will  be  a  source  of  requirements  and  justifications  for  short  turnaround  drills.  The  functional 
staff  at  HQ  TRADOC  integrate  installation  submissions  in  their  mission  areas.  DCSIM  integrates  the 
command's  submission,  staffs  the  action  and  recommends  Chief  of  Staff  approval. 

OMA  funding  supports  operations,  including  automation,  communications,  records  management, 
printing  and  postage,  and  low  cost  (<$100K)  acquisitions.  OMA,  since  it  is  not  IMA  specific,  is 
allocated  to  and  managed  by  all  TRADOC  organizations.  Out-year  planning  for  OMA  requirements  are 
submitted  to  the  Army  POM.  Installations  submit  UFRs  to  document  their  OMA  requirements  for  the 
IMA. 

It  is  important  to  understand  that  the  resource  planning  documents,  e.g..  Army  RDA  Plan  and  UFRs 
simply  state  requirements  for  funds  and  that  approved  requirements,  e.g..  Operational  Requirements 
Documents,  simply  recognize  the  validity  of  an  operational  requirement.  Neither  represent  available 
funding.  That  step  is  left  to  the  programming  and  budgeting  processes.  TRADOC  traditionally  receives 
in  its  operating  budget  far  less  than  is  requested  in  its  planning  documentation. 

5.6  Responsibilities  for  IS  Modernization 

This  section  provides  an  overview  of  organizational  responsibilities  for  managing  projects  to 
modernize  TRADOC's  IS  architecture.  TRADOC  will  not  do  this  alone  so  several  non-TRADOC 
organizations  are  also  listed.  Project-specific  responsibilities  were  given  in  the  paragraphs  above. 
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5.6.1  DoD 


In  an  effort  to  increase  joint  interoperability  and  cut  costs,  the  DoD  has  increasingly  taken  on  more 
centralized  IM  planning  and  execution  responsibilities.  DoD  has  issued  the  TAFIM  to  provide  a 
framework  for  how  to  plan  IS  architecture  based  on  its  TRM.  DoD  also  maintains  the  Defense 
Infommtion  Infrastructure  (DII)  Master  Plan  to  lay  out  their  own  system  architecture  modernization 
planning.  According  to  the  master  plan,  the  DII  is  "a  seamless  web  of  communications  networks, 
computers,  software,  databases,  applications,  data,  and  other  capabilities  that  meets  the  information 
processing  and  transport  needs  of  DoD  users  in  peace  and  in  all  crises,  conflict,  humanitarian  support, 
and  wartime  roles."  The  DoD,  particularly  DISA,  manage  programs  of  major  importance  to  TRADOC. 
TPRISM  already  discussed  components  of  the  DII  in  sections  corresponding  to  their  architectural  niche 
within  the  TRM.  These  included  the  DISN,  COE  and  DMS.  DoD  defines  the  architecture  and  provides 
selective  components  (e.g.,  WAN  backbone)  for  each  of  these  programs.  DoD  also  provides  contractual 
vehicles  for  installations  to  procure  architecturally  compliant  components  to  satisfy  their  own  local 
requirements.  DoD  also  publishes  the  Joint  Technical  Architecture  to  promulgate  standards  necessary 
for  interservice  IS  compatibility.  Lastly,  DISA  also  operates  several  infrastructure  components, 
including  the  DISN,  and  the  Defense  Megacenters  to  centralize  much  of  the  mainframe  processing 
formerly  done  by  the  individual  services. 

5.6.2  Army 

The  Army  is  likewise  increasing  centralized  planning  and  execution  of  IM  programs.  In  planning, 
this  includes  publication  of  the  JTA-Armv.  which  complies  with  the  DoD's  JTA.  and  serves  as  the 
standards  profile  for  all  Army  MACOMs.  The  Army  manages  several  acquisition  programs  important  to 
TRADOC,  e.g.,  PPC4I  through  CECOM,  and  STAMIS,  SBIS  and  ITP  through  PEO  STAMIS. 

5.6.3  TRADOC 

TRADOC  has  IM  responsibilities  for  both  the  Army's  Force  XXI  and  for  the  command's  own 
mission  capabilities.  The  first  looks  external  to  TRADOC,  while  the  latter  looks  internally.  Discussion 
below  shows  how  TRADOC  is  orgamzed  for  these  two  different  missions. 

5.6.3.1  Army-wide  Information  Management 

CG  TRADOC  is  the  Army's  requirements  manager.  In  general,  TRADOC  executes  this 
responsibility  by  producing  doctrine,  organizational  designs  and  materiel  requirements;  and,  by 
approving  requirements  for  all  Army  warfighting  systems  and  systems  in  ACAT I-IIIA.  DCSCD 
executes  the  mission  to  approve  materiel,  or  systems,  requirements.  Also,  DCSCD  is  the  C4I  operational 
architect  for  Force  XXI.  The  procedures  for  requirements  management  are  described  in  TRADOC  Pam 
71-9,  Requirements  Determination. 

DCSCD  has  tasked  CAC  to  develop  a  C4I  operational  architecture  for  Force  XXI,  and  tasked  the 
Signal  Center  to  represent  TRADOC  on  system  architecture  developments.  All  other  schools' 
Directorates  of  Combat  Developments  participate  in  defining  Force  XXI  architecture  and  requirements 
for  their  area  of  proponency. 

TRADOC  is  the  Army's  approving  authority  for  all  M&S  requirements.  The  DCSSA  is  the 
cross-domain  coordinator  and  integrator  for  M&S  requirements.  DCSSA  is  also  responsible  for 
execution  and  functional  management  for  DIS  user  requirements.  This  M&S  requirements  approval 
process  is  also  described  in  an  appendix  to  TRADOC  Pam  71-9,  Requirements  Determination.  The 
M&S  process  includes  review  by  the  Requirements  Integration  Working  Group  and  Council. 

The  Army  M&S  Master  Plan  (1995)  directed  the  formation  of  the  three  Army  level  domains  as  a 
firework  for  organizing  M&S  management:  Training,  Exercises,  and  Military  Operations  (TEMO); 

and  Requirements  (ACR);  and  Research,  Development,  and  Acquisition  (RDA). 
DCSOPS  Army  Modeling  and  Simulation  Office  is  the  single  point  of  contact  for  the  three  domains. 
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Domain  Managers  identify,  inte^ate  and  coordinate  requirements  within  each  domain;  evaluate  existing 
capabilities;  establish  domain  priorities;  develop  and  maintain  a  Domain  Management  Plan;  and  develop 
and  maintain  Domain  Investment  Plans.  The  DCST  and  DCSCD  are  the  Domain  Agents  for  TEMO  and 
ACR  respectively. 

TEMO  domain  functions  are  managed  by  the  TEMO  Executive  Agent  (ADCST-S)  through  the 
TEMO  Action  Agent  staff  (National  Simulation  Center  at  Fort  Leavenworth).  The  TEMO  domain  has 
established  a  TRADOC  Program  Integration  Office  for  the  Synthetic  Training  Environment  (TPIO-SE) 
and  four  TRADOC  Project  Offices  (TPOs):  TPO  Live,  TPO  Virtual,  TPO  Constructive,  and  TPO 
Synthetic  Theater  of  War  (STOW).  The  last  manages  the  combat  developer  and  training  developer 
activities  associated  with  STOW-A. 

The  materiel  developers  are  outside  TRADOC,  e.g.,  STRICOM.  DCSIM  and  DOIMs  provide 
networking  support  for  M&S  connectivity  within  TRADOC. 

5.6.3.2  Internal  TRADOC  Information  Management 

The  DCSIM  at  HQ  TRADOC  is  responsible  for  staff  supervision  and  command-wide 
implementation  of  the  IMA  for  TRADOC.  The  DCSIM  provides  technical  expertise  to  the  TRADOC 
Commanding  General,  staff,  and  16  separate  TRADOC  Army  installation  commanders  on  all  aspects  of 
the  IMA,  and  develops  IMA  policy,  plans,  programs  and  architecture  for  TRADOC's  command-wide  IS 
management.  TPRISM  readers  are  referred  to  the  DCSIM  world  wide  web  page  for  cmrent  information 
on  DCSIM  staff  responsibilities  rhttp://www-tradoc.monroe.annv.mil/dcsim/imorgan.htmy 

The  Deputy  Chief  of  Staff  for  Intelligence  (DCSINT)  is  the  lead  HQ  staff  for  the  IS  security 
program  (ISSP).  DCSINT  has  responsibility  for  vulnerability  assessments,  TEMPEST,  SCI,  and  overall 
IS  security  (ISS)  policy.  DCSIM  is  assigned  responsibility  for  COMPUSEC  (to  include  technical 
solutions,  implementation,  and  network  security)  and  COMSEC.  DCSBOS  is  responsible  for  physical 
security  and  force  protection  aspects  of  the  ISSP. 

TRADOC  installation  commanders  direct  the  command's  DOIMs.  The  1996  functional  area 
analysis  (FAA)  of  the  IMA  preserved  this  relationship.  DOIMs  implement  the  IMA  for  all  activities  on 
their  installation.  They  provide  technical  expertise  to  the  installation  commander  and  all  tenant  activities. 
They  manage  their  installations  IS  architecture,  define  objectives  and  plan  strategy  for  modernizing  their 
IS;  they  document  installation  level  requirements  and  manage  lower  level  requirements  for  their 
installation.  DOIMs  determine  the  high  priority  initiatives  that  can  be  started  within  a  strategy  that  keeps 
its  aim  on  the  objective  system  and  technical  architecture.  They  operate  installation  level  IM  services, 
including  DPIs.  DOIMs  chair  Information  Management  Support  Committees  to  review  installation  level 
projects  and  priorities  for  IS  modernization. 

ISS  mangers  promulgate  secmity  policies  and  procedures  to  ensure  installation  level  security  of 
network  services.  They  sit  on  AJS  configuration  management  boards  as  a  voting  member  to  ensure  all 
new  and  legacy  systems  meet  security  standards  as  outlined  in  AR  380-19.  They  ensure  system 
administrators  submit  AIS  accreditation  requests.  They  ensure  terminal  area  security  officers  (TASO) 
and  network  security  officers  (NSO)  are  appointed  on  orders  and  understand  their  responsibilities.  They 
review  all  proposals  by  DOIMs  to  establish  subscriptions  for  commercial  services,  e.g.  America  on  Line, 
to  establish  security  procedures  and  determine  required  protection  equipment  needs.  They  fimd  security 
training  for  System  Administrators  and  NSO. 
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6.  APPENDIX  A:  TRADOC’s  Technical  Architecture  Standards 


Title 

Title 

Networks 

System  Support  Service 

6.1.1 

Networking  Layer 

Applications 

6.1.2 

Inter-networking  Layer 

6.3.1 

Common  Operating  Environment 

6.1.3 

Host  to  Host  Transport  Layer 

E-mail 

Platforms 

1  Videoteleconferencing 

Hardware-Personal  Level 

Modeling  and  Simulation 

Operating  Systems 

Electronic  document  Exchange  Formats 

TRADOC  uses  the  standards  profile  established  in  the  JTA-Armv,  last  approved  1 1  Sep  97.  Refer  to 
the  worldwide  web  for  version  5.0  and  any  updates.  The  JTA-Army  is  Ijased  on  widely  accepted 
commercial  standards.  TRADOC  will  make  permissible  refinements  and  additions  to  the  JTA-Army  as 
required  to  execute  our  mission  and  maintain  command-wide  information  flow.  This  appendix  provides 
portions  of  the  JTA-Army  which  are  of  primary  importance  within  TRADOC  for  technical  architecture 
compliance.  An  even  more  compressed  overview  is  available  on  the  DCSIM  homepage. 

See  also: 

4.2  Technical  architecture 


For  more  information: 
http://www-ita.itsi.disa.mil/ 

6.1  Networks 

The  JTA-Armv  adopts  widely  accepted,  commercial  standards  regarding  networks  for  transporting 
information.  Specifically,  the  JTA-Army  standards  and  protocols  are  based  on  the  same  open  architecture 
as  the  Internet  and  the  DISN.  The  JTA-Army  primarily  covers  standards  for  packet  switched  networks. 

Effective  information  transport  requires  standardization  by  both  networking  and  computing  system 
components.  There  are  several  ways  to  architect,  or  partition,  information  transport  among  hardware 
components.  The  Government  Open  System  Interconnection  Profile  (GOSIP)  was  previously  the 
standard  mandated  by  DoD,  but  that  is  no  longer  true.  The  JTA-Army  adopts  the  architecture  used  for 
Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP).  Figure  55  shows  how  that  architecture  is 
partitioned,  and  the  particular  standards  JTA-Army  cites  for  each. 

The  networking  layer,  as  shown  in  Figure  55.  is  implemented  by  network  system  components. 
Networks  may  be  relatively  simple  (e.g.,  point-to-point  links)  or  have  complex  internal  structures  (e.g.,  a 
network  of  packet  switches).  Routers  and  hosts  implement  the  higher  layers  shown  in  Figure  55.  Routers 
interconnect  two  or  more  networks  and  forward  packets  across  network  boundaries.  Hosts  are  computers 
that  generally  execute  application  programs  on  behalf  of  users  and  share  information  with  other  hosts  via 
networks.  TPRISM  defers  discussing  the  standards  at  the  user  services  layer  vmtil  paragraph  62^. 
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The  IP  suite  is  several  different  protocols,  defined  in  a  series  of  Request  for  Comments  (RFCs) 
published  by  the  Internet  Architecture  Board  (lAB).  lAB  Standards  (STDs)  are  a  subseries  of  notes 
within  the  series.  The  JTA-Armv  mandates  only  a  subset  of  protocols  within  the  entire  IP  suite. 
Other  protocols  within  the  IP  suite  can  be  used  if  they  provide  services  that  are  not  offered  by  any  of  the 
JTA-Army's  mandated  protocols. 


STANDARDS 

FTP 

STD« 

TEL-NET 

STEM 

BDP  V4 
RPC-irri/ 
XT?  2 

KTTP 

X.40D/ 

X.SOO 

DMS 

DNS 
STD-1 3 

EDOTP 

RPOOai 

DHCP 

RPC-1341 

SNMP 
STD-1 3 

HIL-STD 
3043- 
47  001 

OS  PF 

V2 

STDBS 

TCP  STD-7 

UDP  STD-6 

RPD- 

1SS3 

IP  STD-5 

MIL-STD- 

188.220A 

PPP 

CCFTT 

X.25 

(DCE) 

ISO  S20S 
(DTE) 

IEEE  802.3 
Ethernet  V2 

LLC 

IEEE  802.2 

AAL1 

AAL5 

1X077^6 

(DTE) 

FDDI 

ISO  9314 

ATM 

Rl-S32,449,  S30 
or 

ISDN  (1430,  1.431) 

LAYER 


USER 


HOST  TO  HOST 


INTERNETWORKING 


NETWORKING 

& 

ACCESS 


Figure  55.  Layered  standards  for  information  transport 


6.1.1  Networking  Layer 

The  first  layer  of  information  transport  standardization  covers  internal  networking  and  external 
network  access,  as  shown  in  Figure  55.  The  TCP/IP  suite,  since  it  is  concerned  with  inter-networking, 
does  not  mandate  standards  at  this  layer.  The  JTA-Armv  permits  several  standardization  approaches  at 
this  level,  e.g.,  ATM,  FDDI  and  X.25.  Furthermore,  this  layer  contains  multiple  standards  because  there 
are  multiple  capabilities  that  must  be  standardized,  e.g.,  cabling  and  other  physical  components,  data 
framing,  protocols  to  establish  and  maintain  electronic  links,  error  detection,  synchronization  and  flow 
control  of  signals.  Multiple  approaches  to  standardization  at  this  layer  provide  options  for  a  range  of 
performance  needs,  e.g.,  LANs  vs.  CANs.  Designers  for  information  transport  systems  will  choose 
specific  network  standards  based  on  the  requirements  for  a  given  application,  such  as  cost  and 
speed-of-service. 

6.1. 1.1  Ethernet 

Ethernet  is  the  most  common  LAN  technology  available.  Data  is  transmitted  at  10  Mbps  over  a 
cable,  which  is  shared  by  multiple  hosts.  At  the  physical  layer,  Ethernet  shall  be  implemented  with  any 
of  four  different  types  of  cable.  The  implementations  (and  cable  types)  shall  be  as  defined  by  the  IEEE 
as:  lOBase-5  (thick  coeixial);  lOBase-2  (thin  coaxial);  lOBase-T  (unshielded  twisted  pair);  and  lOBaseF 
(fiber-optic  cable).  Hosts  use  a  carrier  sense  multiple  access  with  collision  detection  (CSMA/CD) 
scheme  to  control  access  to  the  cable.  Ethernet's  physical  layer  and  CSMA/CD  access  scheme  are 
specified  in  IEEE  802.3.  The  interface  between  Ethernet  and  IP  shall  be  in  accordance  with  STD-  41  and 
STD-37. 

For  higher-capacity  requirements,  100-Mbps  Ethernet  technology  can  be  implemented  in 
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accordance  with  IEEE  802.3u.  This  standard  supports  auto-negotiation  of  the  media  speed,  making  it 
possible  for  dual-speed  Ethernet  interfaces  to  run  at  either  10  or  100  Mpbs  automatically. 

•  STD-41  Standard for  the  Transmission  of  IP  Datagrams  over  Ethernet  Networks, 

C.  Homig,  April  1984  (Also  RFC-894) 

•  STD-37  An  Ethernet  Address  Resolution  Protocol,  Nov  1982. 

6.1.1.2  FDDI 

FDDI  is  a  mature  standard  for  high-capacity  LANs  and  CANs.  Data  is  transmitted  at  100  Mbps 
over  either  multimode  or  single  mode  fiber-optic  cable.  FDDI  is  defined  by  a  series  of  ISO  standards. 
These  standards  shall  apply:  9314-1  (physical  layer),  9314-2  (media  access  control),  and  9314-3 
(medium  dependent).  In  addition,  the  Station  Management  (SMT)  protocol  defined  in  ANSI  X3.229 
shall  be  used. 

The  Logical  Link  Control  (LLC)  layer  for  FDDI  shall  be  as  specified  in  IEEE  802.2.  The  interface 
between  FDDI  and  IP  shall  be  in  accordance  with  STD-36. 

•  STD-36  Transmission  of  IP  and  ARP  over  FDDI  Networks,  D.  Katz,  January  1993  (Also 
RFC-1390) 

6.1. 1.3  Asynchronous  Transfer  Mode 

ATM  is  a  high-capacity  switching  technology  that  takes  advantage  of  low  bit-  error  rate 
transmission  facilities  to  accommodate  intelligent  multiplexing  of  voice,  data,  video,  imagery,  and 
composite  inputs  over  high-capacity  trunks.  The  network  access  protocols  to  ATM  switches  are  defined 
in  the  ATM  Forum's  User-Network  Interface  Specification,  Version  3.1.  These  network  access  protocols 
can  operate  over  fiber-optic  and  twisted  pair  cables,  with  data  rates  of  1.5, 2, 45,  51, 100,  and  155  Mbps. 

The  Private  Network-Network  Interface  (PNNI)  Specification,  Version  1  is  mandated.  PNNI 
supports  the  distribution  of  topology  information  between  switches  and  clusters  of  switches  to  allow 
paths  to  be  computed  through  the  network.  PNNI  also  defines  the  signaling  to  establish  point-to-point 
and  point-  to-multipoint  connections  across  the  ATM  network. 

The  protocol  layers  consist  of  an  ATM  Adaptation  Layer  (AAL),  the  ATM  layer,  and  a  physical 
layer.  The  role  of  AAL  is  to  divide  the  variable-length  data  units  into  48-octet  units  to  pass  to  the  ATM 
layer.  There  are  currently  four  defined  AAL  protocols  to  support  different  service  classes.  The  ATA 
mandates  two  of  these  AAL  protocols.  AALl  shall  be  used  to  support  constant  bit  rate  service,  which  is 
sensitive  to  cell  delay,  but  not  cell  loss.  AAL5  shall  be  used  to  support  variable  bit  rate  service.  AALl 
and  AAL5  are  specified  in  ANSI  T1.630  and  T1.635,  respectively.  IP  packets  shall  be  transported  over 
AAL5,  in  accordance  with  RFC- 1577.  Ethernet  can  be  emulated  by  ATM  networks  using  Local  Area 
Network  (LAN)  Emulation  over  ATM,  Version  1.0.  This  permits  ATM  networks  to  be  deployed  without 
disruption  of  host  network  protocols  and  applications. 

6.1.1.4  ITU  X.25 

X.25  is  an  international  standard  that  has  been  widely  adopted  for  packet-  switched  networks.  X.25 
defines  the  interface  between  Data  Terminal  Equipment  (DTE)  and  Data  Circuit-Terminating  Equipment 
(DCE).  The  DTE  generally  refers  to  the  router  or  host  equipment  side  of  the  interface,  and  the  DCE 
refers  to  the  communications  network  side. 

The  standards  that  apply  to  DTEs  are  different  from  (but  fully  compatible  with)  the  standards  that 
apply  to  DCEs.  For  DCEs,  ITU  X.25  shall  be  used  at  the  data  link  and  packet  (i.e.,  intra  network)  layers. 
For  DTEs,  ISO  7776  shall  be  used  at  the  data  link  layer  and  ISO  8208  shall  be  used  at  the  packet  layer. 

At  the  physical  layer,  the  X.25  interface  shall  be  in  accordance  with  Recommended  Standard 
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(RS)-232,  RS-422/423/449,  or  RS530. 

The  method  of  working  IP  with  X.25  interfaces  shall  be  as  specified  in  RFC-  1356. 

6.1. 1.5  Integrated  Services  Digital  Network  (ISDN) 

ISDN  is  an  international  standard  used  to  support  integrated  voice  and  data  over  standard 
twisted-pair  wire.  ISDN  defines  a  Basic  Rate  Interface  (BRI)  and  Primary  Rate  Interface  (PRI)  to 
provide  digital  access  to  ISDN  networks.  These  interfaces  support  both  circuit-switched  and 
packet-switched  services. 

The  BRI  and  PRI  physical  layers  are  specified  by  1.430  and  1.431,  respectively.  The  profiles  for 
BRI  and  PRI  are  National  ISDN  1  and  2,  respectively.  The  BRI  physical  layer  uses  two  wires  to  provide 
two  B  channels  (64  kbps)  for  information  transport  and  one  D  channel  (16  kbps)  for  signaling.  The  PRI 
physical  layer  uses  foiu*  wires  to  provide  23  B  channels  (64  kbps)  for  information  transport  and  one  D 
channel  (64  kbps)  for  signaling.  The  B  chaimels  can  provide  clear  channel  services  or  packet  based, 
point-to-  point  services. 

For  B  channels  configured  for  packet-switched  services,  the  data  link  and  network  layers  shall  be 
the  same  as  specified  in  X.25.  IP  packets  shall  be  encapsulated  and  transmitted  over  ISDN  as  specified 
in  RFC-1356.  For  B  channels  configured  for  clear  channel  services,  IP  packets  shall  be  encapsulated  and 
transmitted  using  PPP  over  ISDN  as  specified  in  RFC-1618.  For  D  channels,  the  data  link  layer  is 
specified  in  Q.921  and  the  network  layer  is  specified  in  Q.931 . 

6.1.2  Inter-networking  Layer 

All  protocols  within  the  IP  suite  use  IP,  specified  in  STD-5,  as  the  basic  data  transport  mechanism. 
IP  provides  a  basic  connectionless  data^am  service  among  heterogeneous  networks.  Two  other 
protocols,  also  specified  in  STD-5,  are  integral  parts  of  IP:  the  Internet  Control  Message  Protocol 
(ICMP)  and  the  Internet  Group  Management  Protocol  (IGMP).  ICMP  is  used  to  provide  error  reporting, 
flow  control,  and  gateway  redirection.  IGMP  provides  multicast  extensions  for  hosts  to  report  their 
group  membership  to  multicast  routers. 

IP,  ICMP,  and  IGMP  are  mandatory  protocols  for  all  hosts  and  routers.  The  profile  shall  be  in 
accordance  with  MIL-STD-2045-14502-1  A. 

•  STD-5  Internet  Protocol,  J.  Postel,  September  1981  (Also  RFC-791,  RFC-950,  RFC-919, 
RFC-922,  RFC-792,  RFC-1112) 

6.1.3  Host  to  Host  Transport  Layer 

Either  STD-6  or  STD-7  will  be  used  at  the  transport  layer.  These  two  protocols  provide 
fundamentally  different  services.  STD-6  defines  the  User  Datagram  Protocol  (UDP),  which  provides  a 
connectionless,  datagram  service  to  applications  not  requiring  reliable,  sequenced  communications. 
STD-7  defines  the  Transmission  Control  Protocol  (TCP),  which  provides  a  reliable,  connection-oriented 
transport  service. 

•  STD-6  User  Datagram  Protocol,  J.  Postel,  August  1980  (Also  RFC-768) 

•  STD-7  Transmission  Control  Protocol,  J.  Postel,  September  1981  (Also  RFC-793) 

6.2  Platforms 

In  the  TRM,  platforms  encompass  the  computing  hardware,  operating  system,  and  system  support 
services.  Each  is  discussed  in  the  sections  below. 

6.2.1  Hardware— Personal  Level 
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The  JTA-Armv  does  not  say  much  about  the  hardware  layer.  It  depends  more  on  standardizing  the 
platforms'  operating  systems  and  APIs  to  ensure  interoperability. 

At  the  personal  platform  level,  ASD(C3I)  issued  the  Department  of Defense  Personal  Computer 
Policy  Implementation  Plan  FY 1995  -  FY 2000.  March  31, 1995.  It  provides  performance  standards  for 
personal  computers  (PCs),  based  on  requirements  for  running  DMS  and  the  Defense  Information 
Infrastructure  (DII)  common  operating  environment  (COE).  It  exempts  only  those  PCs  used  solely  as 
file  servers  or  for  CAD/CAM.  While  not  part  of  the  JTA-Army,  this  guidance  does  contribute  to  the 
standardization  of  personal  computers.  TRADOC  made  permissible  modifications  as  shown  in  Table  5. 
Recommended  PC  configuration. 

6.2.2  Operating  Systems 

These  core  services  are  necessary  to  operate  a  computer  platform  and  support  application  software. 
They  control  applications'  access  to  information  and  the  underlying  hardware.  They  include  kernel 
operations,  shell  and  utilities.  The  JTA-Armv  mandates  Win32  APIs  for  accessing  operating  system 
services  in  sustaining  base  systems,  i.e.,  applications  of  the  type  used  to  support  TRADOC's  internal 
business.  For  other  systems,  which  TRADOC  might  train,  JTA-Army  mandates  the  POSIX  standards. 

•  Win32  APIs,  Microsoft  Win22  Programmers  Reference  Manual,  Volumes  1-5,  1993,  Microsoft 
Press. 

6.2.3  System  Support  Services 

The  TAFIM  TRM  defines  six  system  support  services:  software  engineering,  user  interfaces,  data 
management,  data  interchange,  graphics,  and  network  services. 

6.2.3.1  Software  engineering 

Since  Ada  was  the  mandated  software  engineering  environment  for  so  long,  it  is  worth  stating  here 
that  since  April  1997,  DOD  no  longer  required  the  use  of  Ada.  HQDA  promulgated  this  for  Army  as 
well  in  a  DISC4  memorandum,  SUBJECT:  Selection  of  Third  Generation  Programming  Languages,  28 
Jul  97.  Instead,  developers  will  select  their  programming  language  in  the  context  of  system  and  software 
engineering  factors  that  influence  overall  life-cycle  costs,  risks,  and  interoperability. 

6.2.3.2  User  Interface  Services 

These  services  implement  the  Human  Computer  Interface  (HCI)  style  and  control  how  users 
interact  with  the  system.  The  JTA-Armv  mandates  the  windowing  Win32  APIs  for  sustaining  base 
systems,  i.e.,  applications  of  the  type  used  to  support  TRADOC's  internal  business.  For  other  systems, 
which  TRADOC  might  train,  JTA-Army  mandates  the  Common  Desktop  Environment  which  is  based  on 
X  Window  System  and  Open  Software  Foundation  (OSF)  Motif  See  section  5  of  the  JTA-Armv  for 
details  on  HCI  style,  e.g.,  how  the  screen  looks  and  behaves.  The  following  standards  apply: 

•  Win32  APIs,  Window  Management  and  Graphics  Device  Interface,  Volume  1  Microsoft  Win32 
Programmers  Reference  Manual,  1993,  Microsoft  Press. 

•  FIPS  Pub  158-1,  X  Window  System,  Version  11,  Release  5 

•  OSF,  1992,  Motif  Application  Environment  Specification,  Release  1.2 

•  OSF/Motif  Inter  Client  Communications  Convention  Manual  (ICCCM) 

6.2.3.3  Data  Management  Services 

The  data  management  services  provide  independent  management  of  data  shared  by  multiple 
applications.  These  services  support  the  definition,  storage,  and  retrieval  of  data  elements  from 
monolithic  and  distributed,  relational  DBMSs. 

To  support  the  identification  of  information  and  information  interchange  requirements,  the  DoD  has 
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selected  the  Integrated  Definition  (IDEF)  modeling  methodology.  DoD  Directive  8320. 1-M  requires 
IDEFO  (Integrated  Definition  for  Function  Modeling)  in  accordance  with  FIPS  Pub  183  and  IDEF  IX 
(Integrated  Definition  for  Information  Modeling)  in  accordance  with  FIPS  Pub  184  as  the  presentation 
standard  for  activity  and  data  modeling,  respectively.  Data  model  development  shall  proceed  in 
accordance  with  DoD  8320. 1  -M-X,  which  authorizes  a  single  authoritative  source  for  data  definitions 
and  documentation  standards,  i.e.,  the  Defense  Data  Dictionary  System  (DDDS).  The  DDDS  is  used  to 
collect  and  integrate  individual  data  models  into  a  DoD  data  model  and  to  document  content  and  format 
for  data  elements.  It  is  the  DoD-wide  integration  point  for  standard  data  element  definitions. 

Data  management  services  also  support  platform-independent  file  management  (e.g.,  the  creation, 
access,  and  destruction  of  files  and  directories).  The  JTA-Armv  mandates  the  ANSI  Structured  Query 
Language  (SQL)  standards  with  Ada  interfaces.  The  following  standards  are  mandated  for  any  system 
required  to  use  a  relational  DBMS  for  managing  information  shared  among  multiple  users  or 
applications. 

•  FIPS  Pub  183  Federal  Information  Processing  Standards  Publication  183,  Integration  Definition 
for  Function  Modeling  (IDEFO),  21  December  1993 

•  FIPS  Pub  184  Federal  Information  Processing  Standards  Publication  184,  Integration  Definition 
for  Data  Modeling  (IDEF IX),  21  December  1993 

•  FIPS  Pub  127-2.  Database  Language  -  SQL 

•  ISO  12227:1994,  SQL  Ada  Module  Description  Language 

•  Open  Data  Base  Connectivity,  ODBC  2.0:  Provides  standard  APIs  between  database  application 
clients  and  the  database  server. 

6.2.3.4  Data  Interchange  Services 

The  data  interchange  services  provide  specialized  support  for  the  exchange  of  data  and  information 
between  applications  and  to  and  from  the  external  environment.  Standards  for  these  services  apply  more 
to  system  developers  than  system  users.  TPRISM  readers  needing  to  understand  standards  that  apply  are 
referred  to  the  JTA-Armv.  For  the  users'  perspective,  see  paragraph  6.3.5  regarding  formats  for 
exchanging  applications  software  files  via  e-mail  or  file  transfer  protocol. 

6.2.3.5  Network  Services 

The  technical  architecture  for  some  network  services  was  already  described  in  the  network  section 
above,  paragraph  6J^.  The  reader  is  referred  there  for  information  to  complement  the  description  below. 
The  protocols  discussed  in  the  following  subparagraphs  are  mandated  for  all  hosts  that  require  these 
capabilities. 

6.2.3.5.1  File  Transfer 

Basic  file  transfer  shall  be  accomplished  using  File  Transfer  Protocol  (FTP).  FTP  provides  a 
reliable,  file  transfer  service  for  text  or  binary  files.  While  designed  to  be  used  by  other  programs,  it 
includes  a  direct  interactive  user  interface  to  enable  access  to  remote  file  servers.  FTP  is  specified  in 
STD-9.  The  profile  shall  be  in  accordance  with  MIL-STD-2045- 17504. 

•  STD-9.  File  Transfer  Protocol,  J.  Postel,  J.  Reynolds,  October,  1985.  (Also  RFC-  959) 

6.2.3.5.2  Remote  Terminal 

Basic  remote  terminal  services  shall  be  accomplished  using  TELNET.  TELNET  provides  a  virtual 
terminal  capability  that  allows  a  user  to  "log  on"  to  a  remote  system  as  though  the  user's  terminal  was 
directly  connected  to  the  remote  system.  TELNET  is  specified  in  STD-8.  The  profile  shall  be  in 
accordance  with  MIL-STD-2045- 17506. 

•  STD-8.  Telnet  Protocol,  J.  Postel,  J.  Reynolds,  May,  1983  (Also  RFC-854,  RFC-  855) 
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6.2.3.5.3  E-mail 


The  standard  for  electronic  mail  is  compliance  with  the  Defense  Message  System  (DMS). 
DMS-compliant  X.400  provides  a  full-featured,  electronic  mail  service,  as  specified  in  Allied 
Communication  Publication  (ACP)  123.  Note  that  X.400  is  not  an  Internet  standard,  but  can  operate 
over  IP  networks  through  the  use  of  STD-35. 

6.2.3.5.4  Directory  Services 

International  Telecommunications  Union  (ITU)  X.500  is  mandated  for  use  with  DMS.  X.500  which 
provides  directory  and  secmity  services  that  may  be  used  by  users  or  DMS-compliant  applications  to 
locate  other  users  and  resources  on  the  network.  Note  that  X.500  is  not  an  Internet  standard,  and  must 
operate  over  TCP  through  the  use  of  STD-35. 

6.2.3.5.5  Translating  Names  to  IP  Addresses 

The  Domain  Name  System  (DNS)  provides  the  service  of  translating  between  host  names  and  IP 
addresses.  DNS,  which  uses  TCP  as  a  transport  service,  is  specified  in  STD-13. 

•  STD- 13  Domain  Name  System.  Also  RFC  1034  and  1035. 

6.2.3.5.6  Network  Management 

All  hosts  and  routers  shall  implement  the  Simple  Network  Management  Protocol  (SNMP)  set  of 
management  protocols.  The  set  consists  of  STD-15,  STD-16,  and  STD- 17. 

•  STD- 15  Simple  Network  Management  Protocol,  J.  Case,  M.  Fedor,  M.  Schoffstall,  J.  Davin,  May 
1990  (Also  RFC-1157) 

•  STD-16  Structure  of  Management  Information,  M.  Rose,  K.  McCloghrie,  May  1990  (Also 
RFC-1155,  RFC-1212) 

•  STD- 17  Management  Information  Base,  K.  McCloghrie,  M.  Rose,  March  1991.  (Also  RFC-1213) 

6.2.3.5.7  Dynamic  Configuration 

Dynamic  Host  Configuration  Protocol  (DHCP)  provides  an  extension  of  Bootstrap  Protocol 
(BOOTP)  to  support  the  passing  of  configuration  information  to  Internet  hosts.  DHCP  consists  of  two 
parts:  a  protocol  for  delivering  host-specific  configuration  parameters  from  a  DHCP  server  to  a  host  and 
a  mechanism  for  automatically  allocating  IP  addresses  to  hosts.  DHCP  is  specified  in  RFC  1541.  (NOTE: 
BOOTP  provides  a  mechanism  for  a  disUess  system  to  bootstrap  itself.  BOOTP  is  specified  in 
RFC-951,  with  additional  clarification  provided  in  RFC- 1542.) 

6.2.3.5.8  Hypertext  Transfer 

HyperText  Transfer  Protocol  (HTTP)  is  used  for  search  and  retrieval  within  the  WWW.  HTTP  uses 
TCP  as  a  transport  service.  The  Uniform  Resource  Locator  (URL),  which  specifies  how  objects  are 
identified  with  HTTP,  is  defined  in  RFC-1738  and  RFC1808. 

•  RFC-1866,  Hypertext  Markup  Language  2.0,  3  Nov  95. 

6.3  Applications 

For  the  software  application  layer,  the  JTA-Armv  encourages  domain-specific  application 
architectures,  with  standardized  interfaces  to  lower  level  components,  and  a  commonality  that  grows 
from  using  the  DII  common  operating  environment  (COE).  In  this  way,  common  reusable  software  and 
products  become  the  building  blocks  that  are  used  as-is  or  extended,  if  necessary,  to  meet  different 
operational  requirements,  e.g.,  for  weapons  systems  or  installation  IS. 
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6.3.1  Common  Operating  Environment 

The  DII  COE  is  both  a  collection  of  reusable  software  components  and  a  set  of  architectural 
guidelines  and  standards.  The  guidelines  and  standards  specify  how  to  build  new  software  so  that 
integration  is  seamless  and,  to  a  large  extent,  automated.  Software  components  in  the  COE  are  built  for  a 
"plug  and  play"  open  architecture  designed  around  a  client/server  model. 

The  DII  COE  is  based  on  work  from  the  command  and  control  domain  with  contributions  from 
logistics.  DoD  plans  to  expand  it  to  other  domains  with  different  requirements,  e.g.,  transportation,  base 
support,  personnel,  health  affairs,  and  finance. 

The  JTA-Armv  does  not  mandate  the  use  of  specific  COE  software  products,  since  implementation 
decisions  belong  to  the  Systems  Architecture,  but  it  does  emphasize  the  principle  of  software  re-use. 
Software  designers  will  use  common  support  applications  from  the  COE  software  library  to  the 
maximum  extent  consistent  with  requirements.  DISA  maintains  the  COE  software  in  an  on-line 
confi^ration  management  repository  called  COE  Software  Repository  System  (CSRS).  See  world  wide 
web  site:  http://spider.osfl.disa.mil/dii/coe. 

The  JTA-Army  also  emphasizes  designing  toward  the  COE  architectural  concept.  Fundamental  to 
that  concept  are  segrnentation  and  the  use  of  public  APIs.  All  systems  that  must  be  integrated  into  the 
DII  will  segment  their  applications  in  accordance  with  the  DII  COE  Integration.  Runtime  Specification, 
Version  2.0. 23  October  1995,  and  use  the  public  APIs  fi'om  the  COE  Baseline  Specification  3.1,29 
April,  1997. 

6.3.2  E-mail 

Since  1988,  the  ASD(C3I)  has  championed  the  Defense  Message  System  (DMS)  as  the  standard 
approach  to  electronic  messaging  and  e-mail  for  the  DoD.  ASD(C3I)  has  mandated  that  DMS  will  be  the 
single,  seamless,  end-to-end  global  electronic  messaging  service  for  all  DoD  messaging  requirements, 
encompassing  all  environments:  strategic,  tactical,  fixed,  and  mobile.  The  JTA-Army  reinforces  this  for 
Army  users. 

DMS  implements  internationally  developed  standards.  DMS  compliance  consists  of  at  least 
electronic  messaging  in  accordance  with  X.400  and  directory  services  in  accordance  with  X.500,  and 
interoperability  and  compliance  certification  by  the  DISA  Joint  Interoperability  Test  Center  (JITC). 
Implementation  also  requires  FORTEZZA  cards  for  user  authentication  and  data  integrity.  As  soon  as 
JITC  successfully  tests  and  certifies  DMS  compliant  products,  TRADOC  will  approve  the  acquisition  of 
only  those  e-mail  systems  that  appear  on  the  certified  list.  Noncompliant  messaging  systems  can  be 
procured  only  when  a  transition  path  to  full  DMS  compliance  is  documented  and  approved  by  the  DISA, 
in  accordance  with  CJCSI  5721.01,  Chairman  of  the  Joint  Chiefs  of  Staff  Instruction,  The  Defense 
Message  System  and  Associated  Message  Processing  Systems,  28  June  1993. 

Per  paragraph  4.4.3.2.  TRADOC  recommends  the  acquisition  of  MS  Exchange  as  an  office 
management  product,  to  include  e-mail  capabilities,  to  meet  DMS  compliance  requirements  and  obtain 
support  from  TRADOC  DOIMs. 

6.3.3  Video  Teleconferencing 

ITU-T  H.324,  Terminal  for  Low  Bit  Rate  Multimedia  Commxmication,  March  1996  is  mandated  for 
VTC  terminals  operating  at  low  bit  rates  (9.6-28.8  kbps). 

VTC  terminals  operating  at  data  rates  of  56-1,920  kilobits  per  second  (kb/s)  will  comply  with 
VTCOOl-Revl,  Industry  Profile  for  Video  Teleconferencing,  Revision  1,  dated  April  25, 1995.  The 
profile  provides  interoperability  between  VTC  terminal  equipment,  both  in  point-to-point  and  multipoint 
configurations  for  telephony  applications.  The  following  are  mandated  standards  for  VTC  terminals 
operating  at  data  rates  of  56-1,920  kb/s: 
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•  VTCOOl-Revl,  Industry  Profile  for  Video  Teleconferencing,  Revision  1, 25  April  1995. 

•  ITU-T  H.221,  Frame  Structure  for  a  64  to  1,920  kbit/s  Channel  in  Audiovisual  teleservices,  July 

1995. 

•  ITU-T  H.321,  Adaptation  of  H.320  Visual  Telephone  Terminals  to  B-ISDN  Environments,  March 

1996. 

•  ITU-T  H.224,  A  Real  Time  Control  Protocol  for  Simplex  Applications  using  the  H.221 
LSD/HSD/MLP  channels  ,  November  1994. 

•  ITU-T  H.281,  A  Far-End  Camera  Protocol  for  Videoconferences  Using  H.224,  November  1994. 

•  ITU-T  H.244,  Synchronized  Aggregation  of  Multiple  64  or  56  kb/s  channels,  July  1995. 

Additional  ITU-T  ratified  standards  are  mandated  for  VTC  systems  implementing  multimedia 
applications.  For  VTC  applications  implementing  the  features  of  audiographic  conferencing,  facsimile, 
still  image  transfer,  annotation,  pointing,  shared  whiteboard,  file  transfer,  and  audio-visual  control,  the 
following  standards  are  mandated: 

•  ITU-T  T.120,  Data  Protocols  for  Multimedia  Conferencing,  July  1996. 

•  ITU-T  T.122,  Multipoint  Communication  Service  for  Audiographics  and  Audiovisual 
Conferencing  Service  Definition,  March  1993. 

•  ITU-T  T.123,  Protocol  Stacks  for  Audiographic  and  Audiovisual  Teleconference  Applications 
November  1994. 

•  ITU-T  T.124,  Generic  Conference  Control,  August  1995. 

•  ITU-T  T.125,  Multipoint  Communication  Service  Protocol  Specification,  April  1994. 

•  ITU-T  T.126,  Multipoint  Still  Image  and  Annotation  Protocol,  August  1995. 

•  ITU-T  T.127,  Multipoint  Binary  File  Transfer  Protocol,  August  1995. 

6.3.4  Modeling  and  Simulation 

The  Advanced  Research  Projects  Agency  (ARP A)  Simulation  Network  (SIMNET)  program  helped 
develop  the  Distributed  Interactive  Simulation  (DIS)  standards  and  protocols  (e.g..  Institute  of  Electrical 
and  Electronic  Engineers  (IEEE)  Standard  1278).  The  DIS  protocols  and  standards  establish  a  common 
data  exchange,  using  Protocol  Data  Units  (PDU),  that  supports  the  interoperability  of  heterogeneous, 
geographically  distributed  live,  virtual  and  constructive  simulations. 

There  will  not  be  a  DIS  3.0,  in  the  sense  of  a  follow-on  generation  to  the  current 
IEEE-1278-199(7/8)  2.x  standards.  Future  evolution  of  DIS  is  denoted  DIS-H-.  The  architecture  adopted 
for  DIS-H-  is  High  Level  Architecture  (HLA).  HLA  is  defined  by  an  interface  specification  (with 
corresponding  API),  an  object  model  template,  and  a  set  of  underlying  technical  principles  (rules). 
DIS++  is  a  set  of  standards  supporting  HLA.  HLA  is  the  DOD's  objective  technical  architecture  for 
M&S. 

ARPA  also  developed  the  Aggregate  Level  Simulation  Protocol  (ALSP).  ALSP  is  being  used  to 
interconnect  existing  theater-level  constructive  simulations,  e.g..  Corps  Battle  Simulation,  that  were  not 
designed  to  act  in  a  federation.  ALSP  confederations  will  remain  a  cornerstone  of  joint  force  level 
modeling  and  simulations  for  the  next  few  years  until  HLA  compliant  M&S  are  fielded. 

6.3.5  Electronic  Document  Exchange  Formats 

The  DOD  and  Army  have  not  established  "standards",  in  the  sense  of  mandatory  products,  for 
office  automation.  TRADOC  has  recommended  a  suite  of  office  automation  applications  (see  Table  6L 
While  these  recommendations  are  not  open  standards,  as  the  term  is  used  in  JTA-Armv  and  TPRISM, 
they  will  help  ensure  interoperability  and  technical  support. 

From  the  command's  perspective,  the  minimal  capability  required  for  interoperability  of  office 
automation  products  is  that  they  be  able  to  exchange  files,  e.g.,  as  e-mail  attachments,  with  minimal  loss 
of  information.  Acquisition  of  applications  with  the  file  exchange  capabilities  listed  Table  16  will 
provide  that  interoperability  while  allowing  flexibility  of  office  automation  applications.  Many 
applications  besides  the  original  vendor's  can  read  and  write  these  formats.  They  are  intended  to 
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represent  the  most  capable  formats  that  are  widely  available  and  supported.  The  JTA  and  JTA-Armv  give 
recommended  file  formats  for  additional  file/document  types. 


Table  16.  Mandatory  formats  for  file  exchange 


Document  Type 

Standard  Format 

File  Name  Extension 
(MIME  Type) 

Compound  Document 

MS  Word  6.0 

.doc 

Briefing/Graphic 

Presentation 

MS  PowerPoint  4.0 

•PPt 

Spreadsheet 

MS  Excel 

.xls 

*  Compoimd  documents  contain  embedded  graphics,  tables  and  formatted  text. 
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7.  APPENDIX  B:  Network  Diagrams 

In  the  published  version  of  TPRISM,  this  appendix  contains  diagrams  of  the  baseline  architecture 
for  WAN  access  and  CANs  on  TRADOC  installations.  Readers  of  the  WWW  version  are  referred  to 
http://www-tradoc.armv.mil/netviz/index.html  for  the  same  displays. 

These  graphics,  with  associated  data  in  spreadsheet  format,  are  maintained  by  the  DCSIM.  The  data 
in  this  appendix  was  reported  by  installation  DOIMs  during  May  1997  as  a  result  of  a  DCSIM  data  call. 
DCSIM  solicits  updates  to  this  database  on  a  continuous  basis. 
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8.  APPENDIX  C:  Mission  Applications 


Para 

Title 

\SESEi 

Title 

8J. 

Training  Applications 

83 

Installation  Transition  Processing 
(ITP) 

Standard  Army  Management  Information 
Systems 

M 

SBIS 

\m\ 

ASIMS 

MWRMIS  Modules 

I##! 

Other  STAMIS 

TRADOC  ISMS 

This  appendix  gives  a  brief  description  of  the  mission  applications  referred  to  in  TPRISM.  It 
includes  Standard  Army  Management  Information  Systems  (ST AMIS)  and  installation  support  modules 
fielded  by  the  ITP,  SBIS  and  TRADOC  ISM  programs.  It  also  covers  training  MIS,  mostly  fielded  by 
Army  Training  Support  Center. 

8.1  Training  Applications 
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ATSC  manages  a  libr^  of  training  applications.  More  information  about  them  can  be  found  at 
httn://www.atimp.armv.mi1/ 

Army-wide  Devices  Automated  Management  (ADAM)  -  ADAM  provides  Life  Cycle  Management 
(LCM)  of  training  devices,  distribution  and  redistribution,  storage  and  supply  supporting  training 
ppport  centers  worldwide.  MATS  will  assume  functionality  of  ADAM  or  ADAM  will  be  incorporated 
into  MATS.  Remote  users  (TSCs  and  MACOMs)  cannot  cinrently  access  system. 

Army  Training  Digital  Library  (ATDL)  -  ATDL  provides  a  globally  accessible  digital  repository  of 
Army  doctrine,  training  knowledge  sets,  and  interactive  applications  to  support  training  of  individuals 
and  units.  Offera  information  such  as  doctrinal  literature  (e.g..  Field  Manuals),  abbreviations/acronyms, 
etc.  identified  as  static  documents  and  not  made  available  thr^ough  the  library  from  any  legacy  system. 
Planned  modernization  efforts  focus  on  multimedia;  interactive  training  courseware;  Training  Support 
Packages  (TSP)  containing  structured  situational  templates  for  planning,  preparing  for,  and  conducting 
training;  information  relating  to  Training  Aids,  Devices,  Simulations  and  Simulators  (TADSS)  available 
to  support  training;  unprocessed  After  Action  Review  (AAR)  information  from  Combat  Training  Center 
(CTC)  unit  rotations,  major  exercises,  and  operational  missions;  lessons  learned  derived  from  processed 
and  analyzed  AAR  information  resident  in  the  Army  Historical  Archives  System  (AH AS). 

Automated  Instructional  Management  System  (AIMS)  -  AIMS  is  a  framing  management  system  for 
resident  student  information;  personnel  management,  student  grades  and  records,  and  scheduling.  It  will 
be  replaced  by  AIMS-R. 

Automated  Instructional  Management  System-Redesign  (AIMS-R)  -  AIMS-R  is  a  training 
management  system  for  automating  resident  student  information;  personnel  management,  student  grades 
and  records,  quota  control,  testing,  and  scheduling.  It  supports  course  development/design  for  ASAT. 
Undergoing  pilot  systems  development. 

Army  Modernization  Training  Automation  System  (AMT  AS)  -  AMT  AS  is  a  centralized  database  of 
all  Army  New  Equipment  Training  (NET)  plans.  The  system  provides  the  ability  to  exchange 
information  with  combat,  training,  and  materiel  developers,  and  allows  the  staffing  and  approval  of  new 
NETPs  electronically.  Army  Materiel  Command  is  the  proponent. 

Army-wide  System  for  Automated  Training  and  Doctrine  Development  (ASATD).  A  tool  for 
developing  and  producing  training  and  doctrine  information  and  products.  ASATDsupports  both  the 
WARRIOR  and  WARFIGHTER  components  of  ATXXI  through  its  total  Army  task  based  training  and 
doctrine  database.  This  database  provides  the  foundation  for  both  the  Automated  Instructional 
Management  System-Redesi^  (AIMS-R)  for  institutional  training  and  the  Standard  Army  Training 
System  (S ATS)  for  unit  training. 

Audio-Visual  Library  System  (AVLS)  -  AVLS  tracks  equipment  location,  usage,  and  duplications 
within  Training  Support  Centers  (TSCs).  WOMS  also  captures  TSC  labor  requirements.  Functionality 
will  be  assumed  by  TRAVISS.  Access  is  provided  through  the  use  of  dumb  terminals  and  personal 
computers  within  the  TSCs.  Connectivity  is  limited  to  hardware  or  modem  connection  to  the  installation 
mainframe. 

CALL  Collection  Observation  Management  System  (CALLCOMS)  -  A  collection  of  all  plans  and 
observations  from  training  exercises. 

Conibined  Arms  Training  Strategy  (CATS)  -  CATS  is  the  Army's  overarching  concept  to  develop 
training  strategies  for  the  total  force  in  schools,  units  and  in  self-development.  It  provides  a  means  for 
the  management  and  planning  of  Army  training  and  training  resources  for  Force  XXL  It  captures  all 
tasks  that  are  taught  in  institutions,  in  units,  and  through  self-development  and  the  resources  required  to 
train  those  tasks  to  standard.  Will  eventually  operate  in  ASAT. 

Force  XXI  Training  Database  -  The  FXXI  Training  Database  is  a  prototype  system  consisting  of  three 
databases  supporting  the  FXXI  training  process  that  address  doctrinal  training  tasks  for  Deliberate 
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Attack,  mounted  brigade  level  mission  organizations,  and  simulation  resource  requirements.  The 
training-based  architecture  includes  tracing  and  tracking  of  tasks  from  tactical  level  BOSs  and  major 
brigade  level  tasks  down  to  platoon  level  tasks,  conditions  and  standards  for  a  mounted  brigade 
including  the  brigade's  divisional  "slice."  The  organizational  architecture  includes  the  normal  support 
elements  provided  by  the  division  and  higher  units  to  brigades  engaged  in  combat  operations.  The 
simulation  resource  requirements  architecture  identifies  simulators  and  simulations  with  potential  to 
support  training  of  identified  tasks  from  brigade  down  to  platoon. 

MILES  Army-wide  Tracking  System  (MATS)  -  MATS  automates  data  collection  at  the  user  level 
concerning  usage,  maintenance,  and  inventory  data  for  TADSS.  Creates  summary  data  in  electronic 
format  for  data  sharing  capability  with  other  automated  systems  using  standard  DOD  and  Army  LANs, 
WANs,  and  LHNs.  TRAVISS  will  assume  its  fimctionality. 

Media  Elimination  and  Design  Intelligent  Aid  (MEDIA)  -  MEDIA  assists  the  training  developer  in 
media,  method,  site,  learning  strategy,  category  of  learning,  selection  and  environmental,  and  safety 
assessment. 

Manpower  Staffing  Standards  System  (MS3)  -  MSS  helps  manage  course  variable  data  information 
for  resourcing  input  to  Structured  Manning  Decision  Review  (SMDR)  and  TRADOC  Review  of 
Manpower(TRM).  Application  is  run  on  EBM  CSP  mainframe  using  VM.  It  will  be  replaced  by 
AIMS-R. 

Program  of  Instruction  Management  Module  (POIMM)  -  POIMM  provides  program  management 
and  distribution  of  POI  and  course  administrative  data  in  electronic  format.  Partial  automation  of 
TRADOC  Reg  351-1,  produces  course  administrative  data  and  program  of  instruction  (POI).  Will  be 
part  of  AIMS-R. 

Range  Facility  Management  Support  System  (RFMSS)  -  RFMSS  automates  range  facility 
management.  Allows  users  to  track  events  from  the  time  of  initial  request.  Also  used  to  track  training 
assets,  utilization,  and  inventory  for  the  Army  and  USMC  to  predict  resourcing  requirements. 

DistrilDutes  range  scheduling  information  to  installation  units  and  to  higher  headquarters.  Follow  on 
versions  being  developed.  Fielding  plan  not  final. 

Ranges,  Targets,  STRAC,  and  Ammunition  (RTS  A)  -  RTS  A  helps  determine  resource  requirements 
for  training  assets  and  inventories  available  assets. 

Reception  Battalion  Automated  System  (RECBASS)  -  provides  automated  in-processing  for  new 
soldiers  through  the  reception  battalion  by  updating  soldier’s  personnel  records  and  by  preparing  the 
forms  contained  in  the  individual's  201  and  finance  files.  Data  consists  of  new  soldier  personnel 
information. 

Standard  Army  Training  Systems  (SATS)  -  SATS  provides  an  automated  training  management 
system  designed  to  enhance  the  planning  assessment  and  execution  of  battle-focused  training  resources. 
Produces  Mission  essential  task  lists  (METL),  training  plans,  and  resourcing  reports  for  individual  units. 
This  DA  directed  program  will  ultimately  roll  up  unit  readiness  from  company  size  imits  to  DA.  SATS 
v4.0  was  released  early  FY  1996. 

Standard  Training  Army  After  Action  Reporting  System  (STAARS)  -  provides  standardized, 
automated  storage  and  distribution  system  during  a  training  event  giving  the  commander  a  training 
evaluation  and  resource  utilization  tool,  and  the  Army  a  doctrinal  based  information  collection  system. 

SATS  -  Training  Exercise  Development  System  (TREDS)  -  SATS-TREDS  provides  a  flexible 
task-based  training  exercise  planninjg  capability  which  may  be  used  to  select,  edit,  develop  and  maintain 
training  exercise  materials  for  any  simulation  environment.  Products  include  operations  orders,  maps 
and  overlays,  execution  matrices,  simulation  initialization  files,  and  task  lists  in  go/no  go  format.  Special 
capabilities  include  a  scenario  library,  training  support  package  generation,  multi-echelon,  multi-task 
exercise  planning  linked  to  one  master  event,  and  task  performance  codes  for  various  simulation 


12 


environments. 

Training  Ammunition  Management  Information  System  (TAMIS)  -  TAMIS  is  an  automated  tool  for 
determining  Army-wide  training  ammunition  requirements. 

Total  Army  School  Courseware  Distribution  System  (TASCDS)  -  TASCDS  processes  TASS 
courseware  requests  to  make  distribution  of  BOIP.  Availability  list  is  published  and  accessed  via 
ATTAARS  (Quad  Zero  Data  Base). 

TRADOC  Automated  Training  Scheduling  System  (TATSS)  -  TATSS  Establishes  and  tracks 
resource  requests,  shortages,  conflicts,  and  provides  empirical  data  on  utilization.  Will  be  replaced  by 
AIMS-R. 

Training  Base  Operation  Decision  Support  System  (TBODSS)  -  TBODSS  determines  the  combat 
readiness,  training  load  distribution  and  optimization,  POI  management,  and  logistical  resources 
necessary  to  support  training  strategies  for  a  changing  training  base.  Will  be  replaced  by  AIMS-R.  See 
POIMM  and  TATSS  for  details. 

TRAMOD  Executive  Management  Information  System  (TEXMIS)  -  TEXMIS,  a  node  of  the  Army 
Training  Digital  Libras  (ATDL),  is  a  central  repository  system  for  the  gathering  and  dissemination  of 
training  and  doctrinal  information.  TEXMIS  acts  as  a  bridge  between  proponent  schools  and  imits.  Data 
flow  is  between  proponent  schools,  from  proponent  schools  to  units,  and  units  to  proponent  schools. 
Links  to  Combat  Training  Center  feedback  systems  will  also  be  developed.  The  system  will  hold 
relational  collective,  individual  and  doctrinal  data  developed  within  the  proponent  schools  using  the 
Automated  Systems  Approach  to  Training  (ASAT).  This  data  represents  the  latest,  most  current  training 
and  doctrinal  information.  Relational  data  from  STRAC,  Cost  Factor  Handbook,  CATS,  and  MTOE  will 
be  linked  with  the  ASAT  derived  data  to  form  compatible  information  modules  available  to  units  using 
the  Standard  Army  Training  System  (SATS).  This  relational  information  will  also  be  available  to  other 
automated  system's  use.  An  output  of  the  relational  information  will  be  hyperlinked  document  t)q)es  to 
the  document  side  of  the  ATDL  for  user  review  or  download  through  the  Internet.  TEXMIS  will  be 
incorporated  into  ATDL  and  will  provide  a  critical  portion  of  the  total  ATDL  data. 

Training  Feedback  System  (TFS)  -  TFS  provides  an  observer/Controller  tool  to  evaluate  units  at 
Combat  Training  Centers. 

Training  Mix  Model  (TMM)  -  The  TMM  is  a  mathematical  programming  model  that  selects  a  mix  of 
training  devices  and  methods  that  optimizes  the  use  of  training  resources  that  meet  a  unit's  METL 
(selected  ARTEP/MTP/soldier  tasks)  and  resources  available  to  train  those  tasks  (TADSS,  field 
exercises).  The  results  will  incorporate  constraints  and  restrictions  placed  on  training,  and  will  examine 
approach  to  maximize  effectiveness  or  minimize  costs.  Currently  a  stand-alone  system,  but  will  be 
adapted  to  client  server  system  for  use  in  SATS. 

Training  Management  Warehouse  System  (TMWS)  -  TMWS  manages  all  receiving  and  shipping  of 
Army  Training  Support  Center  products  (Reserve  Component  Configured  Courseware  (RC3),  Graphic 
Training  Aids  (GTA),  (Production  Inventory  Management  for  CTT  &  OFF). 

Training  and  Visual  Information  Support  System  (TRAVISS)  -  TRAVISS  is  envisioned  to  provide 
installation  Training  and  Visual  Information  Support  Center's  (TWISCs)  with  an  automated  application 
that  will  enhance  TWISC  operations  and  productivity,  and  improve  management  capabilities  through 
real  time  data  availability.  Funding  to  support  software  development,  hardware  procurement  and  system 
fielding  has  been  withdrawn.  Possibility  exists  to  review  and  upgrade  existing  FORSCOM  system 
(Training  Support  Automated  Management  System  -  TSAMS),  currently  in  Windows  format,  to  meet 
TRAVISS  requirements. 

TRADOC  Educational  Data  System-Redesign  (TREDS-R)-  Administers  the  correspondence  course 
program  by  enrolling  and  maintaining  student  personal  and  academic  status,  curriculum,  sub-course 
inventory,  and  grading  key  master  data.  To  be  absorbed  by  AIMS-R. 
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Warnet  XXI  Information  and  Management  Support  System  (WIMSS)  -  WIMSS  provides 
automated  support  for  the  concept  development,  acquisition,  fielding,  and  life-cycle  management  of 
TADSS,  including  the  interrelationships  with  other  functional  areas  of  ATSC  and  the  supporting 
systems.  This  project  is  one  facet  of  a  much  larger  effort  within  the  Army  to  provide  a  mutually 
supportive  system  of  local  and  wide  area  network-based  relational  databases  that  can  maintain  uniquely 
developed  data  elements  under  the  control  of  the  appropriate  commands  while  sharing  those  data 
elements  with  other  systems  that  have  use  of  the  information.  This  controlled  sharing  will  assure  that  all 
Army  commands  have  timely,  consistent,  and  accurate  information  from  which  to  formulate  the 
management  decisions  necessary  to  support  effective  and  efficient  Army  training. 

Work  Order  Management  System  (WOMS)  -  WOMS  helps  ATSC  personnel  to  track  work  order 
status,  labor,  materials,  and  overhead  costs.  It  will  be  absorbed  by  TRAVISS. 

8.2  Standard  Army  Management  Information  Systems  (STAMIS) 

Listed  below  are  key  STAMIS  used,  or  scheduled  for  use,  by  TRADOC  installations.  Some, 
collectively  known  as  ASIMS  applications,  are  run  on  platforms  at  a  DMC.  Others  run  on  local 
platforms  that  are  in  vai^ng  stages  of  migration  toward  JTA-Army  conformance.  Some  STAMIS  are 
maintained  in  both  architectures. 

8.2.1  ASIMS 

Standard  Installation/Division  Personnel  System  (SIDPERS)  -  provides  commanders  and  staff  the 
necessary  personnel  information  to  make  decisions  and  manage  active  duty  personnel.  Supports  tactical 
and  sustaining  base  (installation)  operations.  The  current  version,  SIDPERS2.0,  is  an  MVS  application, 
running  on  an  AHMDAHL  5890/600E  at  a  DMC  as  an  ASIMS  application.  SIDPERS-3  will  have 
modules  for  accounting,  assignments,  promotions,  orders  and  pay.  Its  target  architecture  is  a  Pentium 
MX  server  running  SCO  UNIX  and  the  Informix  DBMS. 

Standard  Finance  System  (STANFINS)  -  designed  to  support  at  accounting  at  all  Army  installations 
and  effective  General  Ledger  control  over  all  resources.  STANFINS  provides  disclosure  of  the  financial 
results  of  all  activities;  information  required  for  all  management  purposes;  data  to  serve  all  budgetary 
purposes  and  a  means  for  integrating  Army  financial  data  with  related  data  in  the  accoimts  of  the 
Treasury  Department.  STANFINS  is  run  as  an  ASIMS  application. 

Standard  Army  Intermediate  Level  Supply  System  (SAILS)  -  a  supply  and  financial  management 
system  designed  to  support  stock  control,  supply  management  and  related  financial  management 
functions  between  the  CONUS  wholesale  level  and  direct  supply  level.  SAILS  will  be  replaced  by 
SARRS-  Objective. 

Standard  Financial  Inventory  Accounting  and  Reporting  System  (STARFIARS)— an  interactive 
system  to  record  financial,  inventory,  accounting  and  other  financial  system  to  support  CONUS  Army 
installations  ^d  comparable  overseas  commands  for  the  Defense  Business  Operating  Fund  (DBOF), 
formerly  retail  stock  fund,  used  to  finance  retail-level  inventory.  Provides  aecoimting  support  for  the 
acquisition  of  wholesale-level  material.  Interfaces  with  standard  supply  systems  as  well  and  the  general 
accounting  system.  STARFIARS-MOD  has  been  adopted  as  a  DOD  migration  system  to  replace 
STARFIARS  and  STANFINS. 

Retired  Army  Personnel  System  (RAPS)  -  provides  data  on  retired  Army  personnel  residing  within  an 
installation's  area  of  responsibility. 

8.2.2  Other  STAMIS 

Army  Food  Management  Information  System  (AFMIS)  -  an  automated  system  supporting  the 
management  of  the  Army  Food  Service  Operation,  worldwide.  Includes  modules  for  Automated 
Headcount  (AHC),  the  Dining  Facility  Operations  (DFO),  the  Installation  Food  Adviser  (IFA),  and  the 
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Troop  Issue  Subsistence  Activity  (TISA).  The  TISA,  IF  A,  and  DFO  modules  were  developed  and  are 
fielded  on  the  AT&T  3B2600GR  Reduced  Instruction  Set  Computer  (RISC)  minicomputer.  A 
client/server  version  is  expected  in  1998.  AFMIS  presently  serves  54  Army  installation  users  worldwide. 

Integrated  Facilities  System-Mini/Micro  (IFS-M)  -  provides  functional  information  on  all  aspects  of 
facilities  engineering  activities  as  well  as  a  single  source  database  of  facilities  related  and  budget 
supportive  data  to  assist  managers  at  all  levels  of  command.  The  system  is  operated  and  maintained  on 
locally  controlled  minicomputer  networks  each  composed  of  a  UNISYS  5000/95  or  UNISYS  6000 
minicomputer  at  each  DPW  site  with  a  network  of  EVEREX  486  microcomputers.  The  network  uses 
TCP/IP  protocols.  Approximately  120  sites  use  IFS-M.  There  is  also  an  ASIMS  version  of  IFS. 

Standard  Army  Automated  Contracting  System  (SAACONS)  -  automates  the  operation  of 
installation  contracting  offices  throughout  the  Army,  many  sites  within  the  Defense  Logistics  Agency, 
the  Defense  Commissary  Agency,  and  the  Special  Operations  Command.  Supports  the  entire  spectrum 
of  contracting  functions,  contract  document  processing,  preparation  of  purchase  orders,  tracking  all 
contractual  actions  and  preparing  management  reports.  SAACONS  serves  approximately  210  sites. 
SAACONS  will  be  replaced  by  SPS.  TRADOC  is  using  a  semi-centralized  architecture,  with  three 
SAACON  host  sites  (Gordon,  Eustis  and  Sill)  supporting  twelve  client  sites.  Two  stand  alone  sites 
remain  at  Knox  and  Huachuca.  SAACONS  can  run  on  a  variety  of  hosts,  including  the  UNISYS  5000  or 
6000  series  and  HP  9000/750. 

Unit  Level  Logistics  System  (ULLS)  -  designed  to  operate  at  the  Company  and  Battalion  level  to 
perform  logistics  related  functions.  The  ULLS  platform  is  a  Zenith  486  Dx4/100  using  the  MS-DOS 
6.22  or  hi^er  operating  system. 

Standard  Army  Maintenance  System-Instailation/TDA  (SAMS-I/TDA)  -  provides  information 
required  for  the  day-to-day  management  of  maintenance,  supply,  and  related  requirements.  Provides 
automated  operational  control  of  maintenance  work  requests,  maintenance  management,  and  supply 
functions.  The  system  will  support  maintenance  management  information  flow  to  the  wholesale  level. 
SAMS-I/TDA  runs  on  a  HP  9000-  750  minicomputer  with  PC  terminals. 

Standard  Army  Retail  Supply  System-Objective  (SARRS-O)  -  a  multi-level  system  which  provides 
stock  record  accounting  and  supply  management  for  supply  classes  II,  III(P),  IV,  VII,  and  IX.  It  will 
operate  at  all  levels  of  supply  from  the  Direct  Support  Unit  through  the  TAACOM  level,  and  at  the 
installation  level. 

Standard  Property  Book  System  (SPBS-R)  -  provides  a  means  of  centralizing  property  book 
accounting  and  providing  asset  visibility.  Designed  initially  for  TO&E  units,  the  application 
functionality  has  been  expanded  to  accommodate  installations  and  TDA  imits.  It  operates  in  both 
centralized  and  decentralized  mode.  It  operates  in  two  environments,  MS-DOS  and  VirtuOS.  SPBS-R 
does  not  run  correctly  under  Windows  3.1,  Windows  for  Workgroups  or  Windows  NT. 

Housing  Operations  Management  System  (HOMES)  -  supports  the  day-to-day  functions  of  the 
installation/community  and  MACOM  Housing  Management  Offices,  to  include  the  transient  billet  and 
guest  house  operations.  The  system  has  evolved  from  a  centralized  mainframe  based  system  to  a 
distributed  mini-computer  based  system  with  computers  located  at  each  installation's  housing  office. 
HOMES  operates  on  a  variety  of  platforms,  running  UNIX,  XENIX  or  HP-UX.  The  system  is  composed 
of  five  separate  modules:  Family  Housing,  Furnishings  Management,  Billeting,  System  Administration 
and  Headquarters  Homes. 

Standard  Procurement  System  (SPS)  -  supports  information  processing  and  decision  making  needs  for 
procurements  for  all  DoD  service  components.  It  will  replace  SAACONS. 

Inspector  General  Network  (IGNET)  -  assists  Inspectors  General  in  tracking  and  reporting 
inspections,  investigations  and  requests  for  action.  Runs  on  Intel  based  PCs  at  about  260  worldwide 
sites. 
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Militaiy  Police  Management  Information  System  (MPMIS)  -  includes  several  software  modules  used 
by  military  police  running  on  Intel  based  PCs.  Modules  include  the  Registration  and  Access  Control 
System  (RACS)  and  Security  Management  System  (SMS). 

Army  Medical  Department  Property  Accounting  System  (AMEDDPAS) 

Installation  Materiel  Condition  Status  Reporting  System  (IMCSRS)  -  produces  various  status  reports 
from  installations  and  units  for  reportable  equipment. 

8.3  Installation  Transition  Processing  (ITP) 

ITP  modules  were  originally  fielded  to  run  on  Sun  690  platforms  at  the  DMCs.  They  are  being  converted 
to  run  on  the  SBIS  platform  architecture,  distributed  to  installations. 

Inprocessing  Management  Information  System  (INPROC)  -  Supports  records  management  for 
inprocessing  personnel  and  preparation  of  SIDPERS  transactions. 

Outprocessing  Management  Information  System  (OUTPROC)  —  Supports  records  management  for 
outprocessing  personnel  and  preparation  of  SIDPERS  transactions. 

Transition  Processing  Management  Information  System  (TRANSPROC II)  -  Supports  the 
separation  of  soldiers  from  active  to  inactive  status. 

Personnel  Locator  (PERSLOC)  —  Tracks  military  and  civilian  personnel,  telephone  numbers  and 
addresses. 

Drug  And  Alcohol  Management  Information  System  (DAMIS)  —  Supports  testing  process  for 
identification  and  disposition  of  soldiers  abusing  drugs. 

Education  Management  Information  System  (EDMIS)  —  Supports  record  keeping  and  administration 
of  on  and  off  duty  education  and  financial  aid. 

Master  Schedule  Of  Activities  (MASSCHACT)  —  Schedules  events,  facilities  and  people.  Supports 
protocol  and  suspense  management.  No  longer  fielded  to  new  sites  due  to  lack  of  use  at  installations  that 
received  it. 

Dental  Readiness  System  (DENTRAD)  —  Supports  administration  of  dental  clinics. 

Central  Issue  Facility  (CIF)  —  Manages  issues,  maintenance,  storage  and  accoimting  of  Organizational 
Clothing  and  Individual  Equipment  (OCIE)  at  installation  issue  facilities. 

Record  Update  Utility  (RUU)  —  Utility  used  by  all  DA  ISMs. 

Installation  level  Integrated  Data  Base  (ILIDB)  -  provides  a  common  relational  database 
(INFORMIX)  for  the  other  modules  to  access. 

8.4  SBIS 

The  following  applications  are  grouped  under  the  SBIS  management  framework: 

Budget  Preparation  And  Execution  System-Installation  (BPSI/BESI)  -  provides  automated  means  to 
identify  and  analyze  requirements,  receive  budget  guidance  from  higher  headquarters  and  formulate 
specific  budget  guidance  for  assigned  organizations.  It  also  is  used  to  track  the  execution  of  these 
budgets. 

Budget  Preparation  And  Execution  System-MACOM  (BPSM/BESM)  -  MACOM  level  version  of 
BPSI/BESI 
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Safety  Management  (SAFETY)  --  Supports  accident  reporting  and  safety  analysis  of  human  behavior, 
program  quality,  facilities,  mishaps,  training,  equipment,  supplies,  personnel  and  hazard  data. 

Security  Clearance  Management  System  (SECCLEAR)  —  Supports  security  clearance  reporting  and 
analysis.  Standardizes  personnel  security  processing  of  Active  and  Reserve  Component  military 
members,  civilian  employees  and  affiliated  personnel. 

Automated  Instructional  Management  System  Redesign  (AIMS-R)-  AIMS  was  developed  by  DCST 
and  fielded  to  TRADOC  schools  from  1984  to  1987.  The  SBIS  program  sustains  it  and  plans  to  redesign 
it,  although  due  to  resource  constraints,  not  all  of  the  fimctionality  originally  planned  for 
AIMS-Redesign  will  be  built.  AIMS  provides  administrative  support  to  all  aspects  of  training  at 
TRADOC  schools  and  Army  Training  Centers.  It  helps  manage  data  about  students,  trainees  and 
instructors;  audit  trails  for  enrollment,  recycles,  attrition  and  graduation;  test  validation  and 
administration;  course  effectiveness;  resource  scheduling;  and  historical  personnel  and  academic  trends. 
Each  school  operates  AIMS  independently  on  a  dedicated  VAX  platform.  In  the  baseline,  the  typical 
platform  is  a  VAXl  1/750,  although  Forts  Leonard  Wood  and  Sill  use  an  additional  VAX  1 1/785. 
Interfaces  with  SIDPERS,  RECBASS,  ATRRS,  EIDS.  User  access  AIMS  by  terminals,  or  PCs 
emulating  terminals,  and  all  processing  is  done  by  the  host. 

Real  Property  Management  Tool  (RMAT)  --  Support  for  managing  real  property  (airspace,  land, 
buildings,  housing,  utilities,  and  other  infrastructure).  PM  SBIS  identified  COTS/GOTS  solution  to  meet 
fimctionality.  Tested  at  Fort  Knox.  PM  SB  A  will  not  field. 

Integrated  Requirements  &  Purchase  Request  System  (IRPRS)  —  Generates  requisitions,  purchase 
requests  and  other  transaction  information.  PM  SBIS  will  identify  COTS  /  GOTS  solution  to  meet 
functionality;  PM  SBA  will  not  field. 

DOIM  Management  Information  System  (DOIMMIS)  —  Provides  integrated  system  for  IMA 
management.  PM  SBIS  will  identify  COTS  /  GOTS  solution  to  meet  functionality;  PM  SBA  will  not 
field. 

8.5  MWRMIS  Modules 

Time  Labor  Management  System  -  currently  fielded  at  all  TRADOC  installations  and  allows  for 
electronic  transfer  of  time  cards  for  NAF  employees  from  DCA  to  DFAS  Red  River  NAF  Financial 
Services.  Application  currently  resides  on  PCs  at  each  activity  and  at  the  central  Novell  file  server  at 
each  installation  DCA.  Application  will  be  upgraded  to  Windows  version  in  FY98/99. 

Financial  Management  Budget  System  is  for  all  MWR/NAF  activities  and  has  also  been  fielded  at 
each  TRADOC  installation.  Also  resides  on  PCs  and  Novell  file  server.  Will  eventually  be  on  WAN. 
Data  is  currently  sent  via  modem  to  MACOM  to  our  CFAD  Novell  file  server.  DOS  based  application 
and  will  be  converted  to  Windows  in  FY98  with  fielding  for  FY  98/99. 

Child  Development  Services  Automated  Management  System  -  a  UNIX  and  DOS  system  located  at 
CDS  activities  throughout  TRADOC.  Undergoing  conversion  to  Windows  and  Windows  version  being 
tested  at  Ft  Knox  KY.  Upgrade  fielding  will  begin  in  FY  98  and  continue  through  FY  99.  Will  require 
hardware  upgrade  at  each  installation  which  will  be  fimded  by  DA  (CFSC).  Communication  between 
installation  buildings  will  be  funded  by  installation  DCA  and  could  utilize  PAIRGAIN  solution  or  any 
other  on-line  communication  solution  available  at  installation. 

RECTRAC  and  GOLFTRAC  are  applications  developed  by  Vermont  Systems  and  track  recreation, 
usage,  rental,  and  point  of  sales  data  for  MWR  activities.  Currently  being  fielded  and  will  continue  to  be 
fielded  through  FY  98.  Bliss,  Gordon,  Knox,  Huachuca,  Jackson,  Sill,  McClellan,  Leonard  Wood  have 
been  fielded  RECTRAC  and  all  TRADOC  installations  with  Golf  courses  have  been  fielded  Golftrac. 

FOODTRAK  and  CATERMATE  are  currently  being  fielded.  Both  applications  can  run  on 
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stand-alone  PCs  or  on  file  server.  Foodtrak  will  interface  with  RECTRAC  at  specific  activities. 

Standard  NAF  Contracting  Services  is  under  software  testing  and  acceptance  and  has  not  been  fielded. 
Being  tested  at  Leonard  Wood  and  Gordon. 

8.6  TRADOC  ISMs 

Following  are  the  applications,  collectively  known  as  ISMs,  that  TRADOC  developed  and  fielded. 
TRADOC  expects  a  combination  of  Army  systems  to  replace  the  TRADOC  ISMs  before  2000.  See 
Table  7.  in  TPRISM's  discussion  of  the  objective  architecture,  for  a  crosswalk  of  TRADOC  ISMs  to 
their  replacements. 

AUDIOVISUAL  LIBRARY  SYSTEM  (AVLS)/  WORKORDER  MANAGEMENT  SYSTEM 
(WOMS)  -  Although  a  training  application,  AVLSAVOMS  has  been  considered  a  TRADOC  ISM. 

AVLS  is  designed  to  track  and  account  for  films,  tapes,  equipment,  aids,  and  devices  issued  or  loaned  by 
the  Training  Services  Center  (TSC).  Each  day  requests  for  films,  tapes,  aids,  devices,  and  equipment  are 
made  to  the  TSC.  This  information  is  stored  in  the  AVLS  database.  AVLS  provides  the  capability  to 
track  a  request  during  its  entire  active  life  cycle,  to  provide  a  complete  listing  of  any  and  all  outstanding 
requests  for  audiovisual  support,  and  to  provide,  on  demand,  a  complete  list  of  all  items  on  lo^  to  any 
unit  or  organization.  In  addition,  AVLS  provides  the  capability  to  post  usage  information  against  and 
update  present  information  at  the  user's  convenience. 

WOMS  is  designed  to  track  a  workorder  during  its'  entire  active  life  cycle  by  the  Training  Services 
Center  (TSC)  and  other  organizational  users.  A  complete  itemized  account  of  the  work  order  may 
include  materials,  labor,  and  overhead  data.  WOMS  provides  the  capability  to  post,  add,  or  update 
information.  WOMS  also  provides  a  system  for  warehouse  management  including  an  automated 
inventory  of  supplies.  The  materials  control  section  allows  for  automatic  stock  adjustment  in  response  to 
First  In/First  Out  policy,  automatic  notification  of  low  stock,  warehouse  indexing,  classification  coding, 
request  for  issue  of  shop  stock  from  central  supply  to  a  work  area,  and  necessary  receipts  to  accompany 
such  issues. 

BATCH  UPDATE  MODULE  FOR  MILITARY  PERSONNEL  -  This  batch  module  establishes  and 
maintains  tables  in  the  military  personnel  database.  Files  are  downloaded  from  SIDPERS  and  used  to 
establish/update  records  while  on-line  SIDPERS  transactions  are  passed  in  batch  mode  to  the  DMC  for 
processing  into  SIDPERS. 

CENTRAL  ISSUE  FACILITY  SYSTEM  -  This  system  provides  the  installation's  Cptral  Issue 
Facility  (CIF)  with  automated  line  item  accountability  for  organizational  clothing  and  individual 
equipment  items,  by  size.  Clothing  forms  (DA  Form  3645),  management  reports  and  temporary  issue 
hand  receipts  are  printed  on-line.  Stocking  requests  are  automatically  computed  based  on  demands.  The 
system  "prompts"  the  user  when  reorder  is  required.  This  system  interfaces  with  the  military  personnel 
database;  an  individual's  SSN  is  entered  to  make  an  issue,  and  CIF  clearance  is  determined  by  Transition 
Point  or  Central  Clearance  Agency  during  outprocessing. 

CIVILIAN  PERSONNEL  BATCH  UPDATE  MODULE  -  This  system  establishes  and  maintains  the 
civilian  personnel  database  and  updates  civilian  personnel  information  in  Post  Locator  and  Vehicle 
Registration  Systems.  Information  is  loaded  weekly  from  a  ACPERS  system  tape  in  the  Civilian 
Personnel  Office. 

CIVILIAN  PERSONNEL  INQUIRY  SYSTEM  -  This  system  is  used  by  the  installation  Civilian 
Personnel  Office  and  other  directorates.  It  provides  the  Civilian  Personnel  Office  the  capability  to 
inquire  on  the  records  of  all  civilians  assigned  to  the  installation  and  provides  authorized  users  in  other 
directorates  and  organizations  with  the  capability  to  inquire  on  specific  record  portion(s)  of  individual 
civilians  assigned  to  their  organization. 

DD-1556  TRAINING  -  This  system  is  designed  to  reduce  the  collective  effort  required  to  arrange, 
conduct,  and  evaluate  civilian  training.  It  virtually  eliminates  the  manual  1556  paperwork  generated 
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within  local  organizations  and  increases  quality  control  for  data  submitted.  The  system  reduces  lag  time 
between  DD-  1556  form  preparation  and  Civilian  Personnel  Office  (CPO)  approval  or  Organization 
approval,  depending  on  the  delegation  of  authority  method  that  is  adopted  by  the  installation.  DD-1556 
enables  users  to  create,  review,  and  update  forms,  evaluate  training,  and  prepare/update  individual 
development  plans. 

DD-1556  TRAINING  HISTORY  SYSTEM  -  This  system  provides  a  sub-module  of  the  CPO  1556 
system  that  allows  users  to  query  completed,  closed,  or  canceled  training  request.  This  database  provides 
a  repository  for  previous  training  requests. 

DENTAL  MANAGEMENT  SYSTEM/DENTAL  QUERY  SYSTEM  -  This  is  an  interactive  system 
to  assist  dental  health  care  managers.  A  record  showing  care  provided  and  status  of  dental  health  is 
maintained  for  each  active  duty  soldier.  Readiness  reports  and  summaries  are  available  for  the 
installation  commander,  the  unit  commanders,  the  dental  activity  commander  and  the  dental  clinic 
manager.  The  Dental  Query  system  provides  unit  commanders  with  the  capability  to  query  specific 
dental  health  information  for  command  members. 

ENLISTED  STUDENTS  ENTNAC  STATUS  SYSTEM  -  This  system  is  used  by  the  Installation  AG 
to  monitor  the  status  of  the  ENTNAC'S.  The  module  composes  a  message  of  selected  individuals  for 
electronic  transmission  to  CCF  (Central  Clearance  Facility). 

INPROCESSING  SYSTEM  -  This  system  provides  status  of  personnel  processing  through  the 
Welcome  Center  and  information  on  individuals  who  are  pending  gains  to  the  installation.  On-line 
rosters  designed  to  track  individuals  in  the  Welcome  Center,  and  personnel,  finance,  medical,  and  dental 
records,  can  be  produced. 

INSTALLATION  CLEARANCE  SYSTEM  (ICS)  -  The  Installation  Clearance  System  (ICS)  allows 
the  user  to  clear  soldiers  fi'om  an  installation.  A  batch  program  executed  by  the  DOIM  loads  the  ICS 
database  with  information  on  soldiers  due  to  clear  within  the  next  30  days.  The  unit  PAC  logs  on  to  the 
system  daily  to  view  soldiers  scheduled  to  clear  the  installation  within  the  next  30  days.  The  unit  clerk 
"initializes"  records  for  individuals  due  to  begin  clearance  within  20  days.  A  clearance  form  can  be 
printed  detailing  each  facility  the  soldier  is  required  to  clear.  A  counter  is  started  for  each  initialized 
soldier  tracking  the  number  of  days  the  soldier  has  been  in  the  clearance  system,  to  provide  accurate  and 
prompt  processing. 

Participating  facilities  (for  example,  cablevision,  bank,  credit  union,  Finance  and  Accounting  Office, 
post  libraty,  etc.)  log  on  daily  to  view  individuals  scheduled  for  clearance.  A  15  day  window  is  available 
for  facilities  to  electronically  "sign  off  on  the  electronic  clearance  for  each  record.  The  AG  user  signs 
on  daily  and  "initials"  those  records  meeting  clearance  requirements.  Five  days  prior  to  the  final 
clearance  date,  the  PAC  prints  a  clearance  form  for  each  soldier  who  must  physically  visit  uncleared 
facilities. 

After  the  AG  and  Unit  PAC  determines  the  solder  has  met  all  clearance  requirements  they  are 
responsible  for,  the  AG  user  enters  the  AG  Clear  Date  and  the  Unit  PAC  enters  the  Unit  PAC  Clear  Date 
in  the  system. 

OFFICER’S  RECORD  BRIEF  (ORB)  SYSTEM  -  This  system  allows  access  to  the  seven  sections  of 
the  ORB  either  by  name  or  SSN.  Changes  to  the  ORB  can  be  created  via  SIDPERS. 

ORDERS  SYSTEM  -  This  system  is  designed  to  generate  reassignment,  promotion,  MOS,  enlistment, 
retirement  and  award/pay  type  orders.  Orders  are  generated  by  selecting  order  formats,  headings, 
distribution  blocks,  signature  blocks  and  additional  instructions.  Orders'  formats,  additional  instructions 
and  heading/distribution  blocks/signature  blocks  are  accessed  by  number  and  version  munber,  which 
allows  installations  to  "customize"  orders  according  to  local  policy.  Additions,  changes  or  deletions  can 
be  made  to  the  orders'  formats,  additional  instructions  and  headin^distribution  blocks/signature  blocks 
tables.  The  completed  order  can  be  viewed,  changed  or  canceled.  The  order  number  is  automatically 
generated  and  incremented  using  the  current  Julian  date  plus  the  individual  order  number  for  each  order. 
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Capability  to  print  an  order  on-line  is  provided. 

OUTPROCESSING  SYSTEM  -  This  system  allows  the  user  to  outprocess  an  individual  through 
Transition  Point  or  Central  Clearance  Agency.  The  system  checks  the  clothing  issue  status  of  an 
individual  to  determine  if  the  individual  has  cleared  the  Central  Issue  Facility.  Amval  and  separation 
transactions  are  prepared  for  SIDPERS  and  the  departed  table  is  updated  with  departure  date  and 
forwarding  address.  DD  Form  214  can  be  created  and  printed  on-line. 

POST  LOCATOR  SYSTEM  -  This  system  contains  information  on  all  military  and  civili^  personnel 
assigned  to  the  installation.  Search  for  personnel  can  be  done  by  name  or  by  SSN.  Information  available 
includes  name,  SSN,  grade,  organization  and  telephone  number.  The  system  includes  forwarding  address 
for  departed  military  personnel.  Mailing  labels  for  forwarding  mail  can  be  created  on-line. 

PROPERTY  BOOK  SYSTEM  -  This  system  provides  property  accountability  for  items  accounted  for 
on  installation  and  organization  property  books.  Users  can  query  and  update  their  property  books,  print 
hand  receipts  and  print  management  reports.  The  system  provides  for  accovmtability/responsibility  of 
nonexpendable  items,  durable  items  and  components.  Property  records  are  automatically  updated  each 
month  with  unit  price  changes  from  the  command  data  master  file  (CMDF).  Transactions  for  the 
Continuing  Balance  System-Expanded  (CBS-X)  are  automatically  created  each  month  and  written  to 
tape  for  transmission  to  Depot  Systems  Command  (DESCOM).  An  audit  trail  of  transactions  associated 
with  property  accountability,  to  include  movement  of  items  from  one  hand  receipt  to  another,  serial 
number  changes  and  NSN  changes,  is  maintained. 

REMOTE  AUTOMATED  ISSUE  DOCUMENT  ENTRY/REGISTER  SYSTEM  (RAIDERS)  - 
This  system  simplifies  the  day-to-day  work  of  the  supply/PLL  clerk,  provides  an  automated  document 
register  and  provides  same  day  availability  of  stocks  on  hand  in  the  Supply  Support  Activity  (SSA). 
Requests  for  issue  (DA  Form  2765)  are  input  interactively  and  edited  against  SAILS  code  table  files. 

The  SAILS  asset  balance  file  (ABF)  is  downloaded  each  day  from  the  DMC.  If  the  item  requested  is  on 
hand,  the  ABF  is  decremented,  and  the  item  can  be  issued  the  same  day  as  requested.  If  the  item 
requested  is  not  on  hand,  a  requisition  for  SAILS  is  created.  Latest  status  from  SAILS  is  automatically 
posted  each  day.  The  system  also  provides  users  with  the  capability  to  add,  change  or  delete  PLL  items. 
This  system  eliminates  pre-edit  rejects  from  SAILS,  virtually  eliminates  the  need  to  hand  carry 
requisitions  and  reduces  about  30  percent  of  the  workload  in  the  Data  Conversion  Section. 

REASSIGNMENT  SYSTEM  -  This  system  provides  capability  to  update  milit^  personnel  records 
for  individuals  being  reassigned.  Reassignment  data  is  captured  by  batch  processing  from  the  SIDPERS 
assignment  instruction  file  (AIF)  for  enlisted  permanent  party  personnel,  and  from  SEES  tapes  for 
enlisted  student  personnel  and  for  officer  permanent  party/student  personnel.  Travel  and  port  call 
information  is  provided;  port  call  orders  and  amendments  can  be  updated.  Users  can  view  the 
reassignment  cycle  history.  SIDPERS  transactions  are  created. 

RECEPTION  BATTALION  AUTOMATED  SUPPORT  SYSTEM  (RECBASS)  -  Although  a 
training  application,  RECBASS  has  historically  been  categorized  as  a  TRADOC  ISM  as  well.  This 
system  is  designed  to  in-process  new  soldiers  through  the  Reception  Battalion.  Each  day  the  MEPS 
electronically  transmits  information  on  expected  new  soldiers.  This  information  is  stored  in  the 
Reception  Battalion  database,  TGJAMEP6.  RECBASS  provides  the  capability  to  in-process  new 
soldiers  with  a  minimum  of  additional  input.  Reception  Battalion  personnel  can  add  new  soldiers  not 
included  in  the  MEPS  data  and  IRR  personnel.  After  the  daily  processing  roster  is  complete,  required 
reports  are  prepared  (daily  roster,  listing  for  updating  blood  type,  initial  pay,  etc.)  RECBASS 
inter-operates  with  the  Military  Personnel  System.  SIDPERS  transactions  are  created  when  necessary. 
Necessary  input  for  the  Automated  Clothing  Initial  Issue  Point  System  (ACIIPS)  is  created  by  daily 
batch  program  TGJABOl.  The  system  contains  an  interface  to  AIMS  which  automatically  enrolls  new 
soldiers.  The  system  provides  the  capability  to  create  transactions  for  JSS. 

With  the  use  of  microcomputers  on  Day  2,  the  Personnel  Affairs  Branch  (PAB)  updates  the  new  soldier's 
record  and  prepares  the  forms  contained  in  the  individual's  201  file.  Data  is  downloaded  from  the 
installation  host  computer,  and  after  processing  by  PAB,  verified  data  from  the  microcomputers  is 
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uploaded  back  to  the  host.  After  the  assignment  of  the  soldier  to  a  training  unit  on  Day  3,  transactions 
are  created  for  JSS,  AIMS,  SIDPERS  and  ATRRS.  Additional  rosters  and  reports  are  prepared  and 
forwarded  to  the  training  batteries  as  required. 

RECORDS  INQUIRY  SYSTEM  -  The  purpose  of  this  system  is  two  fold  -  it  allows  users  to  view 
data  from  individuals'  DA  Forms  2A,  B  and  provides  the  SIDPERS  Interface  Branch  (SIB)  with  on-line 
capability  to  monitor  input  fi-om  MILPO  sections.  Transaction  files  list  all  transactions  prepared  as  input 
for  SIDPERS  cycle.  Transactions  are  pulled  off  by  date  for  input  into  SIDPERS  at  close  of  business  each 
day. 

RECORDS  MANAGEMENT  SYSTEM  -  This  system  allows  various  sections  to  query  and/or  update 
military  personnel  records.  The  in-processing  section  can  add  records.  The  military  personnel 
management  section  can  make  personnel  assignments.  The  enlisted  records  section  can  update  EER  data, 
AEA  code  BARSLOCAL/DA  data,  and  Good  Conduct  Medal  data.  The  records  section  can  update 
records  location  data  to  change  location  of  a  service  member's  201  file.  DA  Form  2  can  be  printed 
on-line,  and  SIDPERS  transactions  are  created. 

SECUWTY  MANAGEMENT  SYSTEM  -  This  system  provides  installation  security  managers  with 
current  information  on  personnel  security  clearances.  The  system  provides  managers  with  the  capability 
to  update  security  information  for  each  individual  on  the  installation  database,  without  affecting 
SIDPERS  data.  It  also  provides  designated  DSEC  personnel  with  the  capability  to  transmit  DD  Form 
173  directly  to  Central  Clearance  Facility  and  with  the  capability  to  input  and  print  DA  Form  873.  The 
system  provides  a  weekly  data  update  from  the  Central  Clearance  Facility  (CCF)  regarding  requests  for 
clearance  actions  initiated  by  the  manager. 

STANDARD  INSTALLATION  BUDGET  SYSTEM  (SIRS)-  This  system  is  fielded  and  maintained 
by  Fort  Leavenworth.  Used  to  assist  DRM  and  program  directors  with  analyzing  and  executing  the 
operating  budget. 

SPECIAL  DUTY  SYSTEM  -  This  system  provides  the  capability  to  screen  special  duty  positions  by 
name  of  individual  in  the  position  or  by  position  number.  Special  duty  position  information  can  be 
added,  changed  or  deleted.  Special  duty  memorandums/orders  can  be  created. 

STATION  UNIQUE  SYSTEM  -  This  support  system  contains  installation  unique  data  necessary  for 
the  operation  of  the  ISM's.  Information  utilized  by  this  module  includes:  user  "log  on"  ID's,  user  access 
levels,  pnnter  ID's,  and  literals  for  printing  orders  and  forms.  The  file  is  maintained  by  OSID  personnel 
m  coordination  with  the  users. 

UIC/pODAAC  ORGif^IZATION  SYSTEM  -  This  system  contains  UIC/DODAAC  information  for 
all  units  on  the  installation.  It  allows  several  ISMs  to  interface  with  one  common  file  that  contains 
imique  unit  identification  data  for  an  installation. 

UNIT  PROCESSING  CODE  (UPC)  SYSTEM  -  This  module  contains  the  master  list  of 
units/activities  serviced  by  the  installation.  It  is  a  system  support  module  that  interfaces  with  several 
ISMs.  Contains  command  information  for  medical  and  dental  tracking  support. 

VEHICLE  REGISTRATION  SYSTEM/POST  DISBARMENT  SYSTEM  -  The  Vehicle 
Registration  System  provides  the  Military  Police  access  to  registration  records  maintained  on  all 
non-military  vehicles  and  non-military  weapons  registered  on  the  installation.  It  provides  vital 
mformation  regarding  vehicles  and  drivers.  It  provides  a  management  tool  to  control  access  to  the 
installation,  complete  traffic  and  criminal  investigations,  and  suspension  and  revocation  actions. 

The  Post  Disbarment  system  provides  the  Provost  Marshal  with  limited  data  (name,  SSN,  date  of  bar 
etc.)  on  all  personnel  who  have  been  barred  from  the  installation. 
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APPENDIX  D:  ACRONYMS 


ADLP 

Army  Distance  Learning  Plan 

ACR 

advanced  concepts  and  requirements 

ADN 

Area  Distribution  Node 

ADRP 

Army  DISN  Router  Program 

ALSP 

Aggregate  Level  Simulation  Protocol 

API 

application  program  interface 

ARPA 

Advanced  Research  Projects  Agency 

ASIMS 

Army  Standard  Information  Management  System 

ATM 

asjmchronous  transfer  mode 

ATSC 

Army  Training  Support  Center 

AUTODIN 

Automatic  Digital  Network 

BBS 

Brigade  and  Below  Simulation 

BLRSI 

Battle  Lab  Reconfigurable  Simulator  Initiative 

CALL 

Center  for  Army  Lessons  Learned 

CAN 

campus  area  network 

CATT 

Combat  Arms  Tactical  Trainer 

CBI 

Circuit  Bundling  Initiative 

CBS 

Corps  and  Below  Simulation 

COE 

common  operating  environment 

COTS 

commercial-off-the-shelf 

CRXXI 

Classroom  21st  Century 

CUITN 

Common  User  Installation  Transport  Network 

DCSIM 

Deputy  Chief  of  Staff  for  Information  Management 

DII 

Defense  Information  Infrastructure 

DIS 

distributed  interactive  simulation 

DISA 

Defense  Information  Systems  Agency 

DISN 

Defense  Information  System  Network 

DMC 

Defense  Megacenter 

DMS 

Defense  Messaging  System 

DOIM 

Director  of  Information  Management 

DSI 

Defense  Simulation  Internet 

DTAC 

digital  training  access  center 

DVTC 

desktop  videoteleconferencing 

FAMSIM 

Family  of  Simulations 

FDDI 

fiber  distributed  data  interface 

FEP 

front  end  processor 

FSSD 

Field  Service  Support  Directorate 

HLA 

High  Level  Architecture 
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ICT 

integrated  concept  team 

IEEE 

Institute  of  Electrical  and  Electronic  Engineers 

IM 

information  management 

IP 

Internet  Protocol 

IPT 

integrated  product  team 

IS 

information  system 

ISL 

installation  sequence  list 

ISDN 

integrated  services  digital  network 

ISM 

installation  support  module 

ITP 

Installation  Transition  Processing 

JSIMS 

Joint  Simulation  System 

JTA 

Joint  Technical  Architecture 

JWARS 

Joint  Warfare  System 

JWICS 

Joint  Worldwide  Intelligence  Communication  System 

KEI 

key  enabling  investment 

LAN 

local  area  network 

M&S 

Models  and  Simulations 

MIS 

management  information  system 

MMFO 

multi-mode  fiber  optic 

MTMP 

MACOM  Telephone  Modernization  Program 

MVS 

Multiple  Virtual  Storage  (IBM) 

MWRMIS 

Morale,  Welfare,  Recreation  MIS 

NAP 

New  York  Access  Point 

NDI 

non-developmental  item 

NIPRNET 

not  classified  but  sensitive  IP  router  network 

OSCAR 

outside  cable  plant  rehabilitation 

OSE 

open  system  environment 

PC 

personed  computer 

PDSS 

post  deployment  software  support 

PPP 

power  projection  platform 

PPC4I 

Power  Projection  C4  Infrastructure 

PROFS 

Professional  Office  System 

PSP 

power  support  platform 

RDA 

research,  development  and  acquisition 

RFC 

request  for  comment 

RISC 

reduced  instruction  set  computer 

RJE 

remote  job  entry 

SAP 

semi-automated  forces 

SBIS 

Sustaining  Base  Information  Services 

SID 

Systems  Integration  Directorate 

SIPRNET 

secure  IP  router  network 
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SMFO 

SNA 

STAMIS 

TAD 

TAFIM 

TCC 

TCP/IP 

TEMO 

TPRISM 

TRADOC 

TRM 

VIC 

VTC 

WAN 

WARSIM 

WWW 


single  mode  fiber  optic 

System  Network  Architecture  (IBM) 

Standard  Army  Management  Information  System 
Technology  and  Analysis  Directorate 
Technical  Architecture  Framework  for  IM 
telecommunications  closet  or  Telecommunications  Center 
Transmission  control  protocol/IP 
training,  exercises  and  military  operations 

TRADOC  Plan  for  Reengineering  Information  System  Modernization 

Training  and  Doctrine  Command 

technical  reference  model 

Vector  in  Commander 

videoteleconferencing 

wide  area  network 

Warfighters'  Simulation 

World  Wide  Web 
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